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. Die Erf indung betrif ft ein N System zur {Coordination 
verteilter Programme, Dienstleistungen und Daten mit Hilfe von 
Anwendungsprogrammen in einem N^jtzwerk mit Rechnern, auf denen 
lokale Sof twaresysteme bedienende Koordinations-Server laufen, 
wobei gemeinsame Objekte als Konimunikationsobjekte zum Austausch 
von Nachrichten eingesetzt und Transaktionen zur Realisierung 
von Kommunikatibn verwendet werden, und die Konimunikationsob- 
jekte durch Ob jektidentifikationsnummern eindeutig identif iziert 
werden und nur Pr6£<es^e v £iit ejpner Referenz auf ein 
Kommunikationsobjekt auf dieses liber den jeweiligen lokalen 
Koordinations-Server zugreif en diirf en. 

Unter Objekten sind allgemein fur sich abgeschlossene Ein- 
heiten zur verstehen, die sowohl Daten als auch bestimmte 
Verbal tensweisen enthalten, und die mit der AuBenwelt durch 
Austauschen von Nachrichten kommunizieren bzw. zusammenarbeiten. 
Die AuBenwelt ist dabei insbesondere wiederum durch andere 
Objekte gebildet. Beispielsweise konnen Kunden( -Dateien) , aber 
auch Rechnungen oder Lief erscheine Objekte bilden. Unter Trans- 
aktionen sind andererseits Einheiten von Aktionen zu verstehen, 
die iiblicherweise bestimmte Eigenschaf ten, n&mlich Atomizitat, 
Konsistenz, Isoliertheit und Dauerhaf tigkeit , erfiillen mussen. 
Die Ergebnisse von Transaktionen mtissen gegen Fehler jeglicher 
Art geschtitzt werden. Diese Forderungen werden in der Literatur 
als ACID-Eigenschaf ten bezeichnet und sind in der Praxis vor 
allem bei Datenbankzugrif f en von Bedeutung, insbesondere wenn 
parallele und koordinierte Veranderungen verschiedener EintrSge 
erfolgen sollen. Wenn nun in diesem Fall eine Transaktion nicht 
vollstandig durchfiihrbar sein sollte, so kbnnte dieser Umstand 
zu einem inkonsistenten Datenbestand fvihren. Wesentlich ist hier 
demgemafi , daB eine derartige Transaktion entweder zur GSnze 
richtig oder gar nicht durchgefuhrt wird ( Atomizit&t ) . 

Die rasante Entwicklung von Netzwerktechnologien, die auch 
zur weltweiten Einfvihrung von Internet gefuhrt hat, bringt immer 
mehr neue Anwendungsgebiete mit sich, wie etwa das Erstellen voh 
Programmen durch Koordinieren von im Netz verteilten Programm- 
stiicken und Ressourcen anstatt der Erstellung von sequentiellen 
Programmen, und das Einkaufen von Dienstleistungen im Netzwerk. 
Die hierfur erf orderliche Sof twareunterstiitzung muB ein hohes 
MaB an Zuverlassigkeit und Verf iigbarkeit garantieren. 
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Bei bekannten Systemen werden in erster Linie Nachrichten 
zur Kommunikation und zur Synchronisation von parallel laufenden 
AktivitSten ausgetauscht (sog. "message passing"). Beispiels- 
weise wird bei vielen bekannten Systemen mit speziellen Auf- 
rufen, den RPC-Aufrufen ("Remote Procedure Call"), eine Funktion 
auf einem anderen Rechner im Netz - mit Parameteriibergabe usw t/ 
Shnlich wie bei Aufrufen einer lokalen Funktion - aufgerufen. 
Diese Form von Nachrichtenaustausch zwecks Kommunikation und 
Synchronisation zieht jedoch verschiedene Nachteile nach sich. 
So ist es notwendig, auf zugrundeliegende Hardware-Architekturen 
eingehen zu miissen, wobei auch zumeist die Anpassung von 
Anwendungsprogrammen an neue Hardware-Umgebungen oder aber neue 
Anwendungsanf orderungen hinsichtlich Ef f izienz , Zuverlassigkeit 
und Verf tigbarkeit das Modifizieren des Programmcodes erfordert. 
Welters nehmen diese in der Literatur als Client/Server- 
Architekturen bezeichneten Systeme dem Programmierer weder die 
Synchronisation von gleichzeitigem Datenzugriff noch die 
Replikation von Daten ab. Programme, die mit solchen Systemen 
erstellt werden, weisen naturlicherweise eine hierarchische 
Struktur auf und zerfallen in Client-Komponenten und in Server- 
Komponenten, die beide vom Programmierer zu erstellen sind. Die 
hierarchische Struktur fuhrt bei groBen Anwendungen auch zu 
Performance-Problemen . 

Alternative Ansatze zum Nachrichtenaustausch basieren auf 
der Verwendung gemeinsamer Daten (Objekte) fur die Kommunikation 
und Synchronisation parallel laufender, verteilter Prozesse. Der 
Vorteil dieses Ansatzes ist, daB bei gleicher Machtigkeit eine 
konzeptionell hohere Abstraktion der zugrundeliegenden Hardware 
geboten wird. Programme, die auf diesem Paradigma basieren, 
konnen kurzer und besser wartbar sein. Welters konnen Systeme, 
die gemeinsame Daten bieten, dem Programmierer bei der 
Erstellung von Programmen deren " Server " - Komponente abnehmen. 

Allerdings weisen die existierenden AnsStze, die auf 
gemeinsamen Daten beruhen, in der Regel mehrere der folgenden 
Nachteile auf : 

(a) Es gibt globale Namen fur die Objekte, was bei groBen 
Datenmengen sehr schnell zu Namenskonf likten fiihrt und die 
Moglichkeit, automatisch Objekte aufzuraumen, unterbindet. 

(b) Die Verwaltung der Objekte bietet keine Ausf allsicherheit 



c «- •> e r 

r «-*«•«- r 
*" « r r n ( 

f c re. r 
r <" «- r r f 

bei Netzwerk- und Systemf ehlern . 

(c) Der Lbsungsansatz ist nicht in jede beliebige Programmier- 
sprache einbettbar, d.h. mGglicherweise nur in Form einer 
neuen Sprache verfiigbar. 

(d) Die Atomizitat mehrerer Kommunikationsschritte wird nicht 
geboten. 

(e) Transaktionen werden in der Regel nicht unterstatzt. In den 
wenigen Ausnahmen werden nur klassische Transaktionen unter- 
stutzt, was fur die Koordination verteilter Systeme nicht 
ausreichend ist. Ein fruhzeitiges (nicht isoliertes) 
"Kommit" ( Vollzugsmeldung ) von Untertransaktionen ist nicht 
moglich, so daB Zwischenergebnisse von kooperierenden 
Transaktionen nicht sichtbar gemacht und Sperren in lokalen 
Systemen nicht friihzeitig aufgehoben werden konnen; gerade 
diese beiden Moglichkeiten waren aber wesentlich fur die 
Autonomie lokaler Systeme. Weitere in Zusammenhang mit 
Transaktionen wunschenswerte Eigenschaf ten waren eine 
semantische Kompensation (die ben6tigt wurde, um trotz 
Aufhebung der Isolation von Transaktionen Atomizitat 
garantieren zu konnen) und eine Funktionsreplikation, die 
vorsieht, Teiltransaktionen im Fehlerfall durch andere 
ersetzen zu konnen. 

(f ) Es wird genau ein Verfahren zur Verwaltung der konsistenten 
Sicht d£s logisch gemeinsamen Objektraums auf der verteilten 
Hardware geboten. Damit ist der Programmierer dem System 
hinsichtlich erreichbarer Fehlertoleranz und Performance- 
mdglichkeiten ausgelief ert . 

(g) Das Anbieten von Dienstleistungen, die mit Hilfe der gemein- 
samen Daten realisiert wurden, wird nicht unterstutzt. Eine 
benutzerspezif ische Unterscheidung wSre besonders 
wiinschenswert . 

(h) Das Entfernen nicht langer benbtigter Daten wird nicht 
automatisch unterstutzt . 

(i) Es gibt keine Zugrif f skontrolle: jeder, der den Namen eines 
Objekts errat, darf darauf zugreifen. 

(j) Es gibt keine Moglichkeit, die Berechnungen, die die Objekte 
verwenden, hinsichtlich Wiederherstellbarkeit , nachdem 
Fehler auftreten, zu unterstutzen . 

(k) Das Verhalten des Systems ist unspezif iziert bzw. sind alle 
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Daten verloren, wenn ein partieller Fehler auftritt, d.h. 
wenn beispielsweise auch nur einer der beteiligten verteil- 
ten Rechner einen fatalen Systemabsturz aufweist, bei dem 
z.B. die Daten der* Festplatte zerst5rt wurden. 
In den Aufsatzen "Fault-Tolerance for Communicating Multi- 
database Transactions", eva Ktihn, Proceedings of the 27th Hawaii 
International Conference on System Sciences, ACM, IEEE, 4 bis 7 
JSnner, Hawaii, 1994, Seiten 323-332; "General Purpose Work Flow 
Languages", Alexander Forst, eva Kiihn und Omran Bukhres, Inter- 
national Journal on Parallel and Distributed Databases, Software 
Support for Work Flow Management, Kluwer Adademic Publishers, 
Band 3, Nr. 2, April 1995, Seiten 187-218; "Logic Based and 
Imperative Coordination Languages", Alexander Forst, eva Kiihn, 
Herbert Pohlai und Konrad Schwarz, Proceedings of the PDCS'94, 
Seventh International Conference on Parallel and Distributed 
Computing Systems, ISCA, IEEE, Las Vegas, Nevada, Oktober 6-8, 
1994, Seiten 152-159; und "A Parallel Logic Language for Trans- 
action Specification in Multidatabase Systems", eva Ktihn, Ahmed 
K. Elmagarmid, Yungho Leu, Noureddine Boudriga, International 
Journal of Systems Integration, Vol. 5, 1995, Kluwer Academic 
Publishers, Boston, Seiten 219-252, sind bereits Anregungen fur 
daruber hinaus gehende Losungen enthalten, wie insbesondere der 
Einsatz von lokalen Koordinations-Servern, welche lokale 
Sof tware-Systeme bedienen, und tiber die die Transaktionen zur 
Realisierung von Kommunikation zwischen Objekten durchgefiihrt 
werden sollen. In diesem Zusammenhang wurden auch verschiedene 
Sprachen-unabhangige bzw. in beliebige Programmiersprachen 
einzubettende Prozeduren gefordert, wie etwa urn Transaktionen zu 
beginnen, zu beenden oder abzubrechen. Uberdies wurde bereits 
allgemein eine Replikationsstrategie angesprochen, gemaB welcher 
jede Stelle, die auf ein Kommunikationsobjekt zugreift, ihre 
eigene Kopie erhalt, wobei jedoch eine Kopie als Hauptkopie oder 
primare Kopie von den iibrigen Kopien, den sekundaren Kopien, 
unterschieden wird. Eine solche primare Kopie wird angelegt, 
wenn ein Kommunikationsobjekt angelegt wird. Wenn dieses 
Kommunikationsobjekt zu einer anderen Stelle gesendet wird, wird 
eine sekundare Kopie angelegt und dem Koordinations-Server an 
der anderen Stelle gesendet. Dadurch wird letztlich eine 
Baumstruktur erhalten, in der jeder Knoten jene Knoten kennt, an 
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die eine Kopie gesandt wurde, und jeder nachfolgende Knoten 
(Sohn) den iibergeordneten Knoten ( Vater ) kennt, von dem er die 
Kopie erhalten hat. Am Wurzelpunkt des Baumes liegt die primSre 
Kopie des Kommunikationsob j ektes vor. 

Diese in den genannten Artikeln enthaltenen Anregungen waren 
richtungsweisend, jedoch ermttglichten sie noch keine praktische 
Durchfiihrung der Koordination von verteilten Sof tware-Systemen, 
Dienstleistungen oder Daten. Insbesondere wurden von diesen 
Ansatzen zwar bereits die obengenannten Nachteile (a) bis (e) 
angesprochen, jedoch vor allem fiir die Probleme (f ) bis (k) noch 
keine Lbsungen aufgezeigt. Von den zu losenden Problemen ist das 
Problem (f ) von ganz besonderer Wichtigkeit, da das Argument, 
daB nur mit Low-Level-Nachrichtensenden bzw. Client/Server- 
orientierten Architekturen eine maximale Performance - 
allerdings auf Kosten von wesentlich mehr und auf wendigerer 
Implementierungsarbeit - erreicht werden kann, der Hauptgrund 
dafiir ist, daB sich bisher Ansatze mit gemeinsamen Objekten 
nicht durchsetzen konnten. 

Aufgabe der Erfindung war es daher, ein neues System der 
eingangs angeflihrten Art vorzusehen, das die Erstellung von 
robusten verteilten Anwendungen, wie z.B. sog. ArbeitsprozeB- 
( "Work Flow" ) -Management systemen, Systemen fur verteiltes 
kooperatives Arbeiten ( "CSCW H ), Mulitdatenbanksystemen, ver- 
teilten Hypertext-Systemen usw. , in einfacher und zuverlfissiger 
Weise ermoglicht, wobei die vorstehend genannten Nachteile 
bekannter Vorschlage durch besondere Transaktionskonzepte auf 
der Kommunikationsschicht sowie durch die Auswahlbarkeit von 
mehreren Verteilungsstrategien vermieden werden sollen. 

Das erf indungsgemSBe System der eingangs angefiihrten Art ist 
dadurch gekennzeichnet , 

daB alle Koordinations-Server zusammen als globales 
Betriebssystem festgelegt werden, 

daB die lokalen Sof twaresysteme zumindest durch Funktionen 
zur Kontrolle von Transaktionen, zum Anlegen und blockierenden 
oder nicht-blockierenden Lesen von Kommunikationsob j ekten ; zur 
Spezif ikation von transaktionalen Pradikaten sowie zur Erzeugung 
und Uberwachung von eindeutig identif izierten, zum Zugreifen auf 
libergebene Kommunikationsob j ekte autorisierten Prozessen 
erweitert werden, 
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und daB die Kommunikationsobjekte mit Hilfe von auf Repli- 
kation beruhenden wShlbaren Verteilungsstrategien verwaltet 
werden, von denen die Anwendungsprogramme unabhSngig sind. 

Mit einem solchen System bzw. mit dem damit geschaffenen 
Koordinationsparadigma wird eine vorteilhafte Alternative zu den 
herkommlichen Client /Server-Architekturen erhal ten , wobei 
zahlreiche, nachstehend erlauterte Vorteile erzielt werden. 

Durch das Verhalten der Gesamtheit aller Koordinations- 
Server als weltweites, einheitliches Betriebssystem - wozu die 
Koordinations-Server untereinander ident sind - werden unter 
anderem die Vorteile erzielt, daB eine einheitliche Behandlung 
gesichert ist, daB Anzahl und Orte der Rechner - oder Agenten - 
keine Rolle spielen (es wird mit dem vorliegenden System ein 
spezifisches Netzwerk erhalten), und daB im Falle von verlorenen 
Objekten zumindest jene Telle, die von den verlorenen Objekten 
unabhangig sind, repariert bzw. als konsistente Gesamtheit 
gerettet werden kdnnen. Ferner wird die Programmerstellung mit 
Hilfe des globalen Betriebssystems wesentlich einfacher. Die 
Programmierung der Synchronisation und Replikation von Daten 
wird dem Programmierer abgenommen. Die Programme werden 
einfacher, klirzer und daher besser wartbar . 

Beim vorliegenden System werden globale Namen fur Objekte 
vermieden - jeder ProzeB bekommt in seiner Argumentliste die 
Objektidentif ikationsnummern aller fremden Objekte mit, die er 
sehen darf, wobei er nur liber diese Objektidentif ikationsnummern 
zugreifen kann; andererseits mlissen in verteilten Systemen 
gewisse Objekte doch aufgrund einer Bezeichnung bezogen werden 
konnen (z.B. "WWW Browser" etc.), und dies ist beim vorliegenden 
System moglich. In der geschlossenen Koordinations-Server-Welt 
werden nur Ob j ektidenti f ikationsnummern verwendet, und diese 
konnen nach aufien beispielsweise liber an sich bekannte bzw. 
vorhandene Unterstlitzungen, die liber Datenbankmechanismen eine 
Referenz auf ein Objekt ( sowie ein Zugrif f srecht ) retournieren, 
und die hier der Einfachheit halber "Nameserver" genannt werden, 
exportiert werden. Diese Nameserver konnen auf Basis von 
vorhandenen Unterstlitzungen , unter Verwendung von bekannten 
Datenbanktechnologien, auf Applikationsebene realisiert werden, 
und dabei kann, auf die jeweiligen Bedlirfnisse zugeschnitten, 
ein entsprechender PaBwortschutz bzw. ein Accounting- und 



Indexingmechanismus etc,, der iiber die Koordinations-Server- 
Mechanismen noch hinausgeht, hinzugefiigt werden. Die technische 
Realisierung nutzt die Tatsache permanenter Server aus, bei 
denen ein unendlich lange laufender ProzeB als autonomer und 
automatisch wiederherzustellender ProzeB 13uft, dessen Argument 
der Startpunkt zur Liste aller verwalteten Namen/Objekte ist. 
Dieser ProzeB darf nie terminieren und exportiert die gewiinschte 
Objektidentif ikationsnummer an Anfrager, die den Namen der 
Objektidentifikationsnummer angeben und deren Anfrage als ProzeS 
auf eben diesem Server durchgef iihrt wird. Damit sind beliebige 
DomSnen von Nameservern realisierbar, die in eingeschrSnkten 
Bereichen kontrolliert globale Namen verwalten. 

Das Sicherheitsproblem ist ausreichend gelGst, indem nur 
Prozesse, die rechtmaBig eine Objektidentif ikationsnummer be- 
sitzen - die ihnen entweder mitgegeben wurde, die von ihnen 
selbst erzeugt wurde, oder die erlaubterweise tiber einen 
Nameserver bezogen wurde -, auf Objekte zugreifen diirfen. Damit 
wird iiber die Mechanismen des Betriebssystem hinaus - die vom 
Koordinations-Server-Modell auch gewahrt werden - noch weitere 
Datensicherheit garantiert. 

Ein weiterer Vorteil der erf indungsgemaSen Losung ist, daB 
das Spezif izieren von Dienstleistungen und das Exportieren 
dieser Dienstleistungen an spezifische Benutzer und Gruppen 
unterstiitzt wird. Das erfolgt beim Konf igurieren der 
(x/transienten) Server, bei denen angegeben werden kann, wer die 
jeweilige Dienstleistung konsumieren darf. 

Eine wichtige neue Eigenschaft ist die Unterstiitzung von 
Kommit-Aktionen, deren wesentlicher Vorteil darin liegt, daB der 
Programmierer Berechnungen und das Schreiben von Daten atomar 
zusammengruppieren kann. Es kann beispielsweise zum Ausdruck 
gebracht werden, daB ein neuer "Worker" gestartet werden muB, 
wenn ein bestimmter Wert kommuniziert wurde. Dieser Sachverhalt, 
der auch, wenn die gewahlte Verteilungsstrategie zuverlSssig 
ist, iiber System- und Netzwerkf ehler hinweg garantiert wird, 
macht die Entwicklung von f ehlertoleranten Applikationen sehr 
einfach. Dariiber hinaus kann man davon ausgehen, daB alle 
benotigten Daten automatisch wiederhergestellt werden, und daB 
alle autonomen Prozesse, die noch nicht terminiert batten, 
automatisch wieder angestartet werden. 
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Durch die wahlbaren Verteilungsstrategien ( Konununikations- 
protokolle) ist ein Fein-Abstimmen von ZuverlSssigkeit, Verfvig- 
barkeit, Replikationsverhalten bzw. Performance der Konununi- 
kationsobjekte je nach Bedarf und Zielsetzung moglich, z.B. 
durch wahlweise bestimmbare Protokollf lags , wie "zuverlfissig 
( reliable ) " / "nicht-zuverlassig (unreliable)"; es k6nnen auch - 
in einem Programm - verschiedene Verteilungsstrategien gleich- 
zeitig, fiir verschiedene Kommunikationsobjekte, existieren. 

Dariiber hinaus werden sowohl nur einmal beschreibbare als 
auch aktualisierbare Objekte unterstiitzt, die unterschiedliche 
Vorteile bieten - diese ko-Existenz ist sonst von keinem 
existierenden System bekannt . 

Ferner wird durch die Funk tionserwei terung bzw.-ergfinzung 
der lokalen Sof twaresysteme, somit die Erweiterung von deren 
Sprachen zu sog. Koordinations-Sprachen, nicht nur die 
Kommunikation mit dem globalen Betriebssystem bei Verwenden von 
ansonsten herkbmmlichen Programmiersprachen (z.B. C, Prolog, - 
Java, Fortran, ...) ermoglicht ( abgesehen vom gewiinschten 
Operieren mit den Kommunikationsobjekten, Transaktionen etc.), 
sondern auch - liber das globale Betriebssystem - eine Uber- 
setzung zwischen den verschiedenen Sprachparadigmen erhalten, so 
daB die Kommunikationsobjekte sprachunabhangig sind (und jede\ 
beliebige Art von Daten enthalten konnen ) ; das globale Betriebs- 
system besorgt auch die eventuell erf orderlichen Umsetzungen bei 
verschiedenen Datenf ormaten (z.B. 32 Bit-/ 64 Bit-Datenworte ) und 
Endiantypen ( "big" / " little" ) . Hinsichtlich dieser Funktionser- 
wei terung bzw. -erganzung existieren als Moglichkeiten der 
"Bibliotheks-Ansatz" (bei dem der Programmiersprache die 
gewiinschten Funktionen hinzugef tigt werden ) Oder insbesondere der 
" Einbettungs- Ansatz " (bei dem die Koordinationseigenschaf ten in 
die Programmiersprache "eingebettet " , d.h. integriert werden). 

Die Erfindung ergibt somit gemafi einem Aspekt ein in einer 
ganz spezifischen Weise operierendes System bzw. Netzwerk, in 
dem die verteilten Rechner gemafi einem gemeinsamen, globalen 
Betriebssystem laufen und nach einem zweiten Aspekt SuBert sich 
die Erfindung in einer spezifischen Programmlogik; insgesamt 
erbringt die Erfindung eine wesentliche Vereinf achung in der 
Koordination von Sof tware-Systemen , Dienstleistungen und 
Ressourcen. 




- 9 - 



Als besonders giinstig hat es sich erf indungsgemaS erwiesen, 
wenn bei der Wahl der jeweiligen Verteilungsstrategie eine 
Basisstrategie in Verbindung mit zusatzlichen, optionalen Stra- 
tegieflags gew^hlt wird. Fur die Feinabstimmung der jeweiligen 
Verteilungsstrategie kfinnen hier zumindest verschiedene 
zusStzliche Strategief lags gewShlt werden, bevorzugt aber auch 
eine von mehreren m5glichen Basis-Strategien . 

Welters 1st es von Vorteil, wenn die lokalen Softwaresysteme 
vom jeweiligen Koordinations-Server gestartet werden. Hierbei 
ist es m6glich, den Server als permanenten Server einmal zu 
starten, der dann an bleibt und weiteren Funktionen dienen kann, 
und der auch im Fall von verschiedenen Anwendern nur einen Namen 
erhalt; es ist aber auch denkbar, den Server als (x/-) transien- 
ten Server fur jeden Aufruf gesondert (bzw. auf einem Rechner zu 
einer bestimmten Zeit als alleinigen Server) zu starten. 

Urn den Speicher nicht liber Gebuhr zu belegen, ist es welters 
vorteilhaft, wenn Kommunikationsobjekte, auf die kein lokal 
laufender ProzeS mehr eine Referenz hat, vom jeweiligen Koordi- 
nations-Server automatisch geloscht oder ausdrvicklich freige- 
geben werden. Dadurch werden nicht mehr benotigte Kommunika- 
tionsobjekte in der Art eines " Auf raumens" (sog. "Garbage 
Colllection" ) selbsttatig aus dem Speicher geloscht, so daS 
Speicherplatz gespart wird; dies wird durch die Verwendung der 
nicht-globalen Objektidentif ikationsnummern ermoglicht und auch 
dadurch begiinstigt, dafl die lokalen Softwaresysteme vom Koordi- 
nations-Server gestartet werden. Damit kann der Koordinations- 
Server leicht erkennen, wann ein ProzeS terminiert hat, und dann 
die Ref erenzahler aller Objekte, die dieser ProzeB besitzt - das 
sind alle Objekte, die durch ihm iibergebene Objektidentif ika- 
tionsnummern bezeichnet werden, ferner alle Objekte, die der 
ProzeS selbst angelegt hat, sowie alle Objekte, die Unterobjekte 
von dem ProzeS zugangigen Objekten sind - dekrementieren . Die 
Loschung ist selbstverstandlich abhangig von der jeweiligen 
Verteilungsstrategie, die diese Loschung verzogern kann, bis 
Strategie-spezif ische Bedingungen erfiillt sind. 

Im Hinblick auf eine optimale Nutzung von Moglichkeiten bzw. 
Ressourcen im Netz ist es auch von Vorteil, wenn iiber die sich 
in ihrer Gesamtheit als globales Betriebssystem verhaltenden 
Koordinations-Server heterogene Transaktionen bzw. Unter- 
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Transaktionen auf verschiedene Rechner verteilt werden. 

Vorzugsweise wird im Falle von aktualisierbaren Objekten 
( "updateable objects" ) ein transaktionales Lesen dieser Objekte 
vorgesehen. Auf diese Weise kann beim Kommit der Transaktion 
iiberpriift werden, ob der gelesene Wert noch aktuell 1st. 

Unter den transaktionalen Pradikaten wird vorzugsweise das 
Schreiben in ein Objekt, das Starten einer Untertransaktion, das 
Verteilen eines Teils einer Transaktion auf einen anderen 
Rechner, das Spezif izieren einer Kompensationsaktion bzw. einer 
Kommit- Aktion vorgesehen. Andere transaktionale Pr&dikate k6nnen 
beispielsweise das Testen eines Objekts im Hinblick auf (Un-)De- 
finiertheit, das Lesen eines aktualisierbaren Objekts oder das 
Loschen einer transaktionalen Anforderung (eines transaktionalen 
Requests) sein. Insbesondere ist es hier auch vorteilhaft, daB 
dann, wenn sicher ist, daB eine jeweilige Transaktion eine 
Vollzugsmeldung abgeben (kommitten) wird, eine Kommit-Aktion als 
Berechnung angestartet wird . 

Im Zusammenhang mit der Kontrolle von Transaktionen konnen 
nicht nur das Starten und Abbrechen bzw. Zurlicknehmen von 
Transaktionen schlechthin vorgesehen werden, ebenso wie das 
Kommitten einer Transaktion in einer Form, in der eine Trans- 
aktion automatisch abgebrochen wird, wenn das Kommitten nicht 
erfolgreich ist: urn Transaktionen unter Rettung von bereits 
erfolgter Transaktionsarbeit reparieren zu konnen, kann mit 
Vorteil unter den Funktionen fur Transaktionen auch ein program- 
mierbares Riicksetzen von transaktionalen Operationen, wie z,B. 
das Lesen oder Schreiben von Kommunikationsob jekten, fur den 
Fall von Fehlern bzw- Ausf alien in den Transaktionen vorgesehen 
werden. Der Grund dafiir liegt darin, daB koordinierende Trans- 
aktionen im Gegensatz zu klassischen Transaktionen oft eine sehr 
lange Lebensdauer haben konnen und mit Hilfe der beschriebenen 
Rucknahmeeigenschaf t beispielsweise eine Transaktion, die schon 
lange, z.B. viele Monate, gelaufen ist und teure System- 
ressourcen konsumiert hat, in der aber eine eher unwichtige 
Operation oder Untertransaktion nicht erfolgreich war, dynamisch 
repariert werden kann, ohne damit auf die bereits geleistete 
Transaktionsarbeit verzichten zu nuissen (in frviheren LGsungen 
ware ein Abbruch unabdingbar ) . Dafiir wird eine "schwache" Form 
der Kommit-Funktion, die nicht automatisch den Transaktions- 
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abbruch bedingt, sondern eine Information dariiber retourniert, 
welcher transaktionale Befehl nicht erfolgreich abgeschlossen 
wurde, in Kombination mit dem dynamischen Riicksetzen von 
transaktionalen Befehlen verwendet . 

Die Erfindung wird nachstehend anhand von bevorzugten 
Ausf uhrungsbeispielen, auf die sie jedoch nicht: beschrfinkt sein 
soli, sowie unter Bezugnahme auf die Zeichnung noch naher 
erlautert. Im einzelnen zeigen in der Zeichnung: Fig.l ein 
Prinzipschema zur Veranschaulichung eines Systems, in dem 
Kommunikationsob j ekte fur autonome lokale Softwaresysteme in 
einem globalen Raum zuganglich sind; Fig. 2 ein Schema, das die 
grundsatzliche Architektur einer Konfiguration mit: Rechnern an 
verschiedenen Orten veranschaulicht, wobei in den einzelnen 
Rechnern installierte Koordinations-Server zusammen ein globales 
Betriebssystem definieren; Fig. 3. ein logisches Ablauf schema zur 
Veranschaulichung des prinzipiellen Betriebs der Koordinations- 
Server, und damit des globalen Betriebssystems; Fig. 4 in einem 
logischen Ablauf schema die Behandlung lokaler Requests; Fig. 5 
den allgemeinen Ablauf beim Anlegen und Inspizieren von Kommuni- 
kationsob jekten; die Fig. 6 bis 8 zu Fig. 5 gehorige Funktionen in 
FluBdiagrammen; Fig. 9 mehr im Detail den Ablauf der aus Fig. 4 
ersichtlichen Transaktionskontrolle; die Fig. 10 bis 16 zugehori- 
ge Transaktionen; Fig. 17 den Ablauf von Transaktionalen Befehlen 
(gemaB Fig. 4) mehr im Detail; die Fig. 18 bis 23 zugehorige 
Transaktionale Befehle ( Transaktionsmanager ) sowie Unter- 
Prozeduren hierzu; Fig. 24 den Ablauf im Fall von aus Fig. 4 
ersichtlichen ProzeS-Bef ehlen mehr im einzelnen; die Fig. 25 bis 
31 den Ablauf der zugehorigen Prozesse, die zusammen den ProzeS- 
manager ergeben; und die Fig. 32 bis 40 den Strategiemanager , 
d.h. verschiedene Prozeduren, die eine sog. Verteilungsstrategie 
(ein Kommunikationsprotokoll ) definieren. 

In Fig.l sind schematisch verschiedene autonome Software- 
systeme (lokale Softwaresysteme - LSYS ) 1 bis 7 veranschaulicht, 
denen verschiedene herkommliche Programmiersprachen P.,, P 2 , 
P 3 ....P n _ 1 , P n (wie z.B. C, Prolog, Lisp, Pascal, Fortran, 
Cobol, C+ + usw. ) zugrundeliegen konnen. Die autonomen Software- 
systeme 1 bis 7 konnen dabei als gleichzeitig laufende Prozesse 
dargestellt werden, und sie konnen jeweils als eindeutig defi- 
niertes System mit leiner solchen Programmiersprache angesehen 
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werden; die Systeme 1 bis 7 konnen insbesondere je ein lokales 
Softwaresystem sein, in dem jeweils eine andere 

Programmiersprache zugrundelie^t, so daS diese Systeme 1 bis 7 
nicht: direkt miteinander arbeiten konnen. ( Theoretisch wSre es 
auch denkbar, daB zwei Systeme direkt interaktiv sein ktfnnen - 
diese direkt: interaktiven Systeime werden hier der Einf achheit 
halber als ein System angesehenJ und es ktmnen gegebenenf alls 
auch mehr Systeme, z.B. drei, sjp zusammengef aSt sein.) 

Mit 8 ist in Fi r g--1 ^jw^itej^/ein sog. Agentenraum veranschau- 
licht, wobei die jeweiligen, nachstehend noch n&her zu erl^u- 
ternden Agenten Objekte 9 bis 17 zur Verfugung stellen. Diese 
Objekte 9 bis 17 sind hier beispielsweise einmal beschreibbare 
( "write-once" ) Objekte, gegebenenf alls auch aktualisierbare 
( "updateable" ) Objekte, und sie konnen als Einheiten Oder 
Behalter mit Kommunikationsdaten angesehen werden; sie bilden 
Kommunikationsobjekte, die in dem gemeinsamen, den verschiedenen 
lokalen Systemen 1 bis 7 zuganglichen "Obj ektraum" enthalten 
sind. Zugang zu den einzelnen Kommunikationsobjekten 9 bis 17 
ist dabei nur liber einen der Agenten moglich. 

Eine Hauptaufgabe der Agenten besteht darin, den gleichzei- 
tigen Zugang zu Objekten 9 bis 17 so zu ermoglichen, daB alle 
Teilhaber, die diese Objekte 9 bis 17 sehen diirfen, zu jeder * 
Zeit die selbe konsistente Sicht von ihnen haben. Insofern liegt 
eine Ahnlichkeit zu einem verteilten Datenbanksystem vor, das 
Transaktionen an den, mehreren Teilnehmern zuganglichen 
Datenob j ekten bietet . 

Das Management von Aktivitaten umfaSt auch die Spezif ikation 
von Aufgaben, d.h. von Programmen, die durch bestimmte Software- 
systeme auszufuhren sind. Eine abgegebene ProzeB-Anf orderung 
( ProzeB- "Request " ) kann als Vertrag zwischen dem anfordernden 
Softwaresystem und einem der Agenten betrachtet werden, der 
dafur verantwortlich ist, 'daB die Aufgabe von einem bestimmten 
( anderen ) Softwaresystem durchgefiihrt werden wird. Der Start 
einer Berechnung ist der Beginn einer neuen Interaktion zwischen 
dem Anfragenden und dem Durchf iihrenden. 

Die Objekte sollen alle Arten von kontrollierbaren AusfSllen 
in den Systemen uberleben. Wenn bestimmte Umstande eingetreten 
sind, miissen sie bestehen bleiben, da global sichtbare Umst&nde 
nicht geloscht oder geandert werden konnen, nachdem andere 
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Prozesse sie . gesehen und ihre Berechnungen auf ihnen aufgebaut 
haben. Es ist notwendig, sich auf die iibermittelten Daten ver- 
lassen zu konnen. Sobald ein wri>te-once Objekt ein definiertes 
Objekt (d.h., ein "nicht-leerer ^ehSlter" ) wird, ist es eine 
konstante "GroBe" mit hoher Zuverlassigkeit - Es kann beispiels- 
weise ( im Falle der write-once-Objekte ) nicht derart manipuliert 
werden, daB es zu einem spSteren \ Zeitpunkt andere Daten enth&lt. 

Aktivit&ten werden implizit jsynchronisiert , da dann, wenn 
ein System vom Erg6bn£s ^ .jpjanes^anderen Systems abhangig ist, es 
weiB, welches Objekt die Daten enthalt, und es einfach darauf 
zugreifen kann. Wenn die Daten noch nicht bereit sind, wird ein 
System, das auf sie zugreifen will, einfach eine langere 
Zugrif f szeit benotigen. 

Fur die vorstehenden Anf orderungen werden im vorliegenden 
System die nachf olgenden, nachstehend noch naher erlauterten 
Koordinations " werkzeuge" vorgesehen, die in die einzelnen 
lokalen Systeme und Programmiersprachen eingebaut werden: 

- die Kommunikat ionsob j ekte bilden einen zuverlSssigen; 
abstrakten Kommunikationsmechanismus 

. - es werden spezifische Transaktionsf unktionen vorgesehen; und 

- es werden spezielle Sprachkonstrukte zur Sicherung von 
Parallelitat vorgesehen . 

Alle Stellen, die an einer Kommunikation teilnehmen, haben 
eine einheitliche Sicht der von ihnen geteilten ( "shared" ) 
Datenobjekte . Auf die Objekte kann zugegriffen werden, als 
wtirden sie in einem lokalen Rechner vorliegen und in das 
jeweilige Sof twaresystem derartig eingebettet sein, daB sie von 
lokalen Daten praktisch nicht unterschieden werden konnen. 
Insofern kann dann, bei entsprechender Einbettung in die lokale 
Software (was eine entsprechende Erganzung derselben hinsicht- 
lich Funktionen bedingt; Ausf uhrungsbeispiele zur ErgSnzung der 
Semantik der Basisf unktionen der Sof twaresysteme , um mit den 
Kommunikat ionsob jekten zu operieren, werden nachfolgend noch 
naher erlautert ) , die Kommunikation iiber diese Objekte als 
Kommunikat ionsmedien erfolgen, wobei iiber diese Kommunikations- 
objekte auch verschiedene Sof twaresysteme kommunizieren kttnnen, 
da aus ihrer Sicht diese Kommunikationsob jekte wie lokale 
Objekte erscheinen. Fur den Programmierer stellt sich das System 
als global verfugbarer Raum dar, auch wenn dieser tatsSchlich 
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iiber eine Vielzahl von Stellen verteilt ist, vergleichbar einer 
groBen verteilten Datenbasis. Jeder interaktive ProzeB hat sein 
eigenes Fenster in diesen globalen Raum, aber alle Prozesse 
haben dieselbe Sicht auf das Objekt. Wenn Daten noch nicht 
verfiigbar sind, muB ein ProzeB war-ten, anstatt mit nicht - 
aktuellen Daten zu operieren. In einem derartigen . lokalen Raum 
halt der ProzeB in ublicher Weise lokale Daten. Die Datentypen 
im lokalen Raum und im globalen Raum miissen selbstverstSndlich 
kompatibel sein . 

Die Kommunikationsobjekte konnen von beliebigem Typ sein, 
d.h. es kann nur einmal ein Wert zugeordnet werden, Oder sie 
konnen wie Variable aktualisierbar sein. Jeder ProzeB kann sich 
auf die aus dem globalen Raum ausgelesenen Daten verlassen, da 
sie ( im Fall von write-once Objekten) sich nicht andern bzw. 
wiederherstellbar sind. Die Kommunikationsobjekte haben weiters 
eine eindeutige Identif ikationsnummer , jedoch keinen globalen 
Namen. Diese Ob jektidentif ikationsnummern (OID) werden zweck- 
maBig uber die bereits erwahnten Nameserver exportiert, die auf 
Applikationsebene unter Verwendung bekannter Datenbanktechno- 
logien realisiert werden. Die Kommunikationsobjekte werden 
zwischen Prozessen durch Ubergabe als Argumente geteilt. Ein 
ProzeB, der keine Referenz auf ein Kommunikationsob jekt besitzt, 
erhalt keinen Zugang zu diesem. Der Agent, der die Kommunika- 
tionsobjekte unterhalt, hindert Prozesse daran, den Bezug auf 
ein Kommunikationsob jekt zu "erschleichen" . Auf diese Weise wird 
eine Sicherheit insofern gewahrleistet , als nur berechtigte 
Prozesse Zugriff zu den Daten haben. 

Ein Kommunikationsob jekt kann strukturiert sein, und es kann 
andere Kommunikationsobjekte als Komponenten enthalten. Derarti- 
ge Sub-Kommunikationsob jekte sind neue "KommunikationsbehSlter" , 
die Werte unabhangig vom sie umschlieBenden Kommunikationsob jekt 
erhalten konnen. Dies wird nachstehend anhand eines Beispiels 
(Beispiel 1: Produzent-Konsument-Problem ) noch mehr im Detail 
aufgezeigt werden. 

Damit alle Prozesse, denen Kommunikationsobjekte gemeinsam 
sind, eine konsistente Sicht dieser Objekte haben, kdnnen Werte 
nur durch Transaktionen in den global geteilten Raum geschrieben 
werden. 

In vorteilhaf ter Weise moglich sind beim vorliegenden 



Koordinations-System welters Funktionsreplikation, Aufgabe der 
Isolations-Eigenschaft von ineinander geschachtelten 
Transaktionen sowie eine semantische Kompensation. 

Die Funktionsreplikation fufit auf der Notwendigkeit , eine 
Dienstleistung, die nicht gutging, durch eine andere zu 
ersetzen, die dieselbe Aufgabe in Squivalenter Weise erfilllt. 
Auf diese Weise kann eine komplexe Aufgabe, die aus einer Anzahl 
von Unterauf gaben zusammengesetzt ist, zu Ende geftihrt werden, 
selbst wenn ein lokales System ausfailt. 

Die Aufgabe der Isolations-Eigenschaft ist aus zwei Grunden 
von Bedeutung: Zum einen wurde dann, wenn beim Koordinieren von 
lokalen Datenbanksystemen eine Unteraktion Sperren im lokalen 
Datenbanksystem sowie das Halten dieser Sperren bis zum Ende der 
globalen Aktion erfordern wurde, das Autonomieprinzip wesentlich 
beeintrachtigt werden. Insbesondere waren dann langlebende oder 
auch "ewige" Prozesse (wie der Produzent-Konsument-ProzeS, s. 
nachf olgendes Beispiel 1) ein bedeutendes Problem. Aus diesem 
Grund durfen Sub-Transaktionen vollenden (in der Datenbank- 
Terminologie: Kommitten), bevor der Gesamtprozefl beendet wird. 
Zum anderen erfordert ein kooperatives Arbeiten, daB Zwischen- 
ergebnisse sichtbar werden, bevor der globale ProzeB terminiert. 
Unterauf gaben konnen nicht auf Daten von anderen Unterauf gaben 
warten, bis der globale ProzeB zu Ende gefiihrt ist. 

Die semantische Kompensation ist sodann die logische Folge 
der Aufgabe der Isolations-Eigenschaft. Es kann beispielsweise 
der Fall eintreten, daB nach erf olgreichem AbschluB eine Aktion 
nicht benotigt wird ( etwa zufolge Funktionsreplikation) oder 
eine Aktion verworfen werden muB (wenn die globale Aufgabe 
endgiiltig scheitert ) , Eine Transaktion, die "kommittet" wurde, 
darf jedoch nicht ruckgangig gemacht werden, da andere autonome 
Prozesse moglicherweise bereits ihre Ergebnisse "gesehen" und 
ihren Berechnungen zugrunde gelegt haben . Wenn ein ProzeB sp&ter 
entscheidet, daB eine Transaktion nicht ben6tigt wird, muB 
hierftir eine semantische Kompensation vorgesehen werden. Eine 
vom Benutzer definierte Kompensationsaktion kann fur diesen 
Zweck spezifiziert werden, und sie wird dann automatisch 
aktiviert und kann ein anderes Kommunikationsobjekt schreiben. 

Da die zu koordinierenden Sof twaresysteme bereits existieren 
und an verschiedenen Stellen parallel laufen, ist Parallelitat 
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im System erforderlich. 

Die Parallelitat zwischen Prozessen ist wesentlich fUr die 
gegenseitige Koordination, und sie kann durch entsprechende 
Spracherweiterung vorgesehen werden, wodurch ein ProzeB (an 
einer anderen) Stelle erzeugt und gesteuert werden kann, und 
wodurch Kommunika t ionsob j ek te ubergeben werden kbnnen, die 
zwischen der einen Stelle und der anderen Stelle, wo der neue 
ProzeB hervorgeruf en wird, geteilt ( ge" shared" ) werden. Die 
Rechner-Stelle und das Sof twaresystem, wo der ProzeB ausgefiihrt 
werden soil, konnen spezifiziert werden. Von vornherein wird die 
jeweilige lokale Stelle als solche angenommen, und der ProzeB 
wird als ProzeB ( wenn moglich als sog. "thread") des Systems, 
durch das er aufgerufen wurde, durchgef uhrt . Dadurch wird eine 
ausreichende Parallelitat zwischen den Prozessen sichergestellt . 
An sich ist Parallelitat innerhalb eines Prozesses nicht 
notwendig fur das vorliegende Koordinations-System, wohl aber 
Parallelitat zwischen Prozessen. 

Die vorstehend im Zusammenhang mit Fig.l erw&hnten Agenten 
werden durch lokale Serverprozesse dargestellt, die 
Koordinations-Server genannt werden. Uberall, wo das vorliegende 
Koordinations-System laufen soli, muB ein derartiger 
Koordinations-Server vorhanden sein, der das jeweilige lokale 
Sof twaresystem erganzt und bedient, wie sich auch aus dem 
Architektur-Schema von Fig. 2 ergibt. 

Im einzelnen ist gemaB Fig. 2 an verschiedenen Stellen bzw. 
Rechnern X, Y, Z zusatzlich zu den lokalen Sof twaresystemen 18, 
19, 20, die durch die nachstehend noch naher zu erlauternden 
Erganzungen fur das vorliegende Koordinations-System erweitert 
sind (was durch die Bezeichnung " & Co" bei den jeweiligen Pro- 

grammiersprachen P 17 P ? P n-1' P n ; also P i & c °/ p 2 & Co ' P 3 

& Co P n-1 & Co, P n & Co, angedeutet ist) jeweils ein 

Koordinations-Server 21, 22 bzw. 23 vorhanden. Diese Koordina- 
tions-Server 21, 22, 23 sind die vorerwahnten "Agenten" (s. auch 
Schraffur in Fig.l und 2) und definieren so den vorstehend 
anhand von Fig.l erlauterten " Agentenraum" , und sie bilden 
zusammen ein globales Betriebssystem 24. Zu diesem Zweck sind 
die Koordinations-Server ( "CoKe" - "Coordination Kernel") 21, 22, 
23 untereinander gleich ausgebildet, und es ist gleichgviltig fur 
die Bildung des globalen Betriebssystems , wie viele Koordi- 
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nations-Server 21, 22, 23 im Einzelfall vorhanden sind. Dieses 
globale Betriebssystem 24 fuhrt dazu, daB es fur den Beniitzer 
gleich ist, ob ein ProzeB lokal oder an einer entfernten Stelle 
l&uft; die identen Koordinations-Server 21, 22, 23 verhalten 
sich gleich, und durch diese Globalitat ergibt sich eine 
Datenabstraktion; ein Zugriff auf ein Objekt an einer entfernten 
Stelle verhait sich wie ein Zugriff auf ein lokales Objekt - der 
Beniitzer merkt hier keinen Unterschied, und er sieht in diesem 
Zusammenhang keine Nachrichten. 

Gem&S Fig. 2 wird beispielsweise das Objekt 9 vom Agenten 
(Koordinations-Server) 21 angelegt und sodann zu den Agenten 22 
und 23 weitergereicht . Die Agenten fungieren dabei als verteilte 
"Transaktionsmanager" . Ganz allgemein kann jeder Koordinations- 
Server als die Module (1) Transaktionsmanager; (2) ProzeB- 
manager; (3) Strategiemanager ; (4) Recovery- ( Wiederherstell- ) 
manager enthaltend angesehen werden. 

Das globale Betriebssystem 24 ergibt sich hinsichtlich 
seiner allgemeinen Funktion aus Fig .3 und mehr im Detail 
hinsichtlich der Transaktionskontrolle aus Fig. 4 bis 9 in 
Verbindung mit den Fig. 10 bis 23 (Transaktionsmanager); der 
ProzeBmanager ist aus Fig. 24 in Verbindung mit den Fig. 25 bis 31 
ersichtlich, und der Strategiemanager (der aus Einzel-Managern 
SMi fur die jeweilige Verteilungsstrategie besteht ) aus den 
Fig. 32 bis 40. 

Der Recoverymanager, auf den z.B. in den Fig. 13, 14, 15 
sowie 28, 30 und 32 bezug genommen wird, enthalt die folgenden 
wesentlichen Elemente: 

Atomarer Schritt START 

Atomarer Schritt ENDE 

Atomarer Schritt ABBRUCH 
Dabei werden Aktionen, die zwischen START und ENDE 
passieren, entweder alle ausgefuhrt, Oder keine davon; d.h. bei 
einem Systemfehler zwischen START und ENDE wird keine Aktion 
durchgef uhrt . 

Je nach der verwendeten Strategie ( unter Setzen von Flags ) 
erfolgt die Ausfiihrung zuverlassig ( ausf allsicher ) , d.h. Effekte 
werden in Log- und Datenfile protokolliert ( gespeichert ) , oder 
nicht zuverlassig . 

Dises Verf ahren gilt auch fur einen geschachtelten Auf ruf 
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von START/ENDE. 

Bei einem Aufruf von "Atomarer Schritt ABBRUCH " werden alle 
Ef f ekte annuliert - 

In Fig. 3 ist der prinzipielle Arbeitsablauf , namlich die 
Hauptschleife, des vorliegenden Systems, und zwar im Bereich des 
globalen Betriebssystems 24 bzw. des jeweiligen Koordinations- 
Servers 21, 22 oder 23, in Form eines FluSdiagramms schematise*! 
veranschaulicht . Wie dabei ersichtlich ist, wird nach einem 
Initialisierschritt 25 und einem Wiederherstellschritt 26, in 
dem alle vom Koordinations-Server 21, 22 bzw. 23 bentitigten 
Daten vom Datenfile oder vom "Logfile" wiederhergestellt werden, 
sowie einem Schritt 27 , in dem ein unabhangiger , noch nicht 
terminierter , momentan nicht aktiver ProzeS P definiert wird, 
beim Schritt 28 abgefragt, ob die ProzeBliste P leer ist, d.h. 
ob kein solcher ProzeS P gef unden wurde . Wenn dies nicht 
zutrifft, wird der ProzeSmanager aufgerufen, urn - gemaB Block 29 
- den ProzeS P auf zuspannen, wonach zum Schritt 27 zuruckgekehrt 
wird . Das Auf spannen eines Prozesses ist ein Unterprogramm, das 
nachstehend anhand der Fig. 31 noch naher erlautert werden wird. 

Wenn das Abf rageergebnis bei 28 positiv ist, d.h. kein 
ProzeS P vorliegt , wird im Schritt 30 zur Ausf uhrung getrigger- 
ter Arbeit ubergegangen , und im Schritt 31 wird auf ein nSichstes 
Ereignis E gewartet . Im Schritt 32 wird dann abgefragt , ob 
dieses Ereignis E eine Nachricht von einem anderen Koordina- 
tions-Server ist. Falls dies nicht zutrifft, wird sodann bei 33 
abgefragt , ob das Ereignis E ein Request von einem lokalen 
Sof twaresystem ist ; falls nein, wird das Ereignis E im Schritt 
34 als Konsolen-Bef ehl behandelt; falls ja, wird das Ereignis E 
als lokaler Request behandelt, und zwar gemaB einer mit Block 35 
angegebenen Prozedur , welche nachstehend anhand der Fig . 4 noch 
naher erlautert wird . Ist hingegen das Ereignis E eine Nachricht 
von einem anderen Koordinations-Server, so wird gemaB Block 36 
der Strategiemanager aufgerufen , urn das Ereignis E als Nachricht 
von einem anderen Koordinations-Server zu verarbeiten, wie 
nachstehend anhand der Fig. 33 noch naher erlautert werden wird. 

Nach alien drei Schritten 34, 35 bzw. 36 wird in der 
Programm-Hauptschleif e gemaB Fig. 3 anschlieSend zum Block 27 
zuruckgekehrt, urn den selben Zyklus hinsichtlich eines nachsten 
unabhangigen Prozesses P zu durchlauf en . 
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Wie aus Fig, 4 ersichtlich ist, wird im Unterprogramm, Block 
35 in Fig. 3, einleitend im Schritt 37 der Request ( Ereignis E in 
Fig. 3) als lokaler Request: R definiert. Bei 38 wird sodann 
abgefragt, ob der Request F* eine giiltige Anfrage eines 
Koordinations-Servers ist. Falls nein, wird im Schritt 39 eine 
Fehlermeldung erzeugt, und es wird sofort zum Ende dieses Unter- 
programms 35 iibergegangen. Falls R jedoch eine giiltige Anfrage 
ist, wird gem£S Block 40 (s. auch nachstehende Erl^uterung zu 
Fig. 5) zu einem Unterprogramm betreffend Anlegen und Inspizieren 
von Kommunikat ionsob j ekten iibergegangen; weiters folgt ein 
Unterprogramm, Block 41 (s. auch Fig. 9), betreffend Transakti- 
onskontrolle, sodann ein Unterprogramm, Block 42, betreffend 
transaktionale Befehle (s. Fig. 13) und schlieSlich im Block 43 
ein Unterprogramm "ProzeB-Bef ehl " (s. auch nachstehende 
Erlauterung zu Fig. 24. Mit diesen Teilen 40 bis 43 wird somit 
die Art des jeweiligen lokalen Request R untersucht, und es 
werden die gewunschten Vorgange bewirkt . 

Nachstehend werden anhand der Fig. 5 bis 40 die zum Teil 
bereits allgemein angesprochenen, zum Teil noch nicht erwShnten 
Befehle bzw. Funktionen naher erlautert, wobei ganz allgemein, 
wie bereits auch aus den Fig. 3 und 4 zu erkennen war, fur die 
Darstellung in den Zeichnungsf iguren gilt, dafl mit st&rkeren 
Linien dargestellte B16cke auf in der Folge zu erlSuternde 
Figuren verwiesen wird, die entsprechende Blocke mit starker 
Umrandung, zwecks Verdeutlichung des Zusammenhangs , zeigen. 

Die nachfolgend unter Bezugnahme auf die Fig. 5 bis 40 
beschriebenen Befehle kGnnen als Erweiterung einer traditio- 
nellen Sprache zu einer " Koordinations " sprache ( im Wege einer 
Bibliothekserweiterung oder einer Einbettung in die jeweilige 
Programmiersprache ) angesehen werden. Die hier angegebenen 
Bezeichnungen der Befehle sind aber selbstverst&ndlich beliebig 
und nur als Beispiele zu verstehen. Die verwendete Beschreibung 
stutzt sich im allgemeinen auf eine Programmiersprachen-neutrale 
Syntax und ist unabhangig von den Datentypen der jeweiligen 
" Gas t" sprache. Die Durchfiihrung der Befehle erfolgt in den 
Koordinations-Servern oder Agenten; die als bloBe Beispiele 
angegebenen Bef ehlsbezeichnungen (wie "cobj_create" etc.) 
gehoren zur Anwender-Schnittstelle, wobei damit die Bedeutung 
der Erweiterung der Programmiersprachen ( P^ wird zu P^ & Co) 
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erkennbar wird . 

Als erstes wird nun der allgemeine Ablauf beim Befehl zum 
Anlegen und Inspizieren von Kommunikationsobjekten, Block 40 in 
Fig. 4, anhand der Fig. 5 naher erlautert. Dabei wird in ver- 
schiedenen Abfragen die Art des lokalen Requests R eruiert, und 
abhangig davon werden unterschiedliche, im folgenden anhand der 
Fig. 6, 7 und 8 n&her erlauterte Funktionen im Zusammenhang mit 
Objekten bewirkt . 

Im einzelnen wird einleitend bei 44 abgefragt, ob der lokale 
Request R ein Request zum Anlegen eines neuen Objekts 1st. Wenn 
ja, wird zum Block 4 5 " Ob jekt anlegen" (s. Fig. 6) iibergegangen. 
Wenn nein, wird als nachstes abgefragt, ob der eingelangte 
lokale Request ein Request zum "Objektlesen" ist (Abfrage 46). 
Wenn ja, wird im Block 47 (s. Fig. 7) der Befehl "Lesen eines 
Objekts" ausgefuhrt. Wenn nein, wird als dritte Abfrage bei 48 
gepruft, ob der lokale Request R ein Request zum alternativen 
Warten ( Uberwachung von Objekten) ist. Wenn ja, wird das Unter- 
programm alternatives Warten, Block 49 (s. Fig. 8) aufgerufen; 
wenn nein, wird im Ablauf gemaB Fig. 4 zum Block 41 iibergegangen. 

Es folgt nun eine Erlauterung der vorstehend angesprochenen 
Funktionen, wobei nur fur jene, die an die Anwender- 
Schnittstelle exportiert werden, Namensbeispiele angegeben 
werden . 

- Anlegen eines Objekts: OID <- cobj_create( Typ, Strategie) 

( s . Fig . 6 ) 

Diese Funktion dient dazu, ein neues Kommunikationsobjekt 
anzulegen, wobei als Antwort eine eindeutige Ob jektidentif i- 
kationsnummer (OID) fur das neue Objekt retourniert wird. 
Diese OID wird an andere Befehle als Argument weiterge- 
reicht. Gewiinschtenf alls kann beim Anlegen des neuen Objekts 
- als sog. Option - eine Verteilungsstrategie selektiert 
werden, "def ault "maBig (d.h. vom System vorgeschlagen ) wird 
eine Standardstrategie verwendet . Der beim Anlegen 
definierte Typ spezif iziert , ob es sich urn ein nur einmal 
beschreibbares Objekt ( write-once-Objekt ) oder urn ein 
aktualisierbares Objekt ( "up-dateble'^Objekt ) handelt. 
Weiters wird, wie aus Fig. 6, Block 45, ersichtlich ist, eine 
neue Ob jektstruktur angelegt, die vom lokalen Agenten 
verwaltet wird, die durch die OID eindeutig gekennzeichnet 
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ist, und die ein neues Kommunikationsob j ekt darstellt. Der 
Objektstatus ist zunachst nicht definiert ("UNDEFINED"), und 
es wird eine Objektzeitmarke definiert (und gleich Null 
gesetzt ) . 

Lesen eines Ob j ekts: Value <- cobj_read( BlockingFlag, OID) 
(s. Fig. 7) 

Diese Funktion wird fiir nicht aktualisierbare Kommuni- 
kationsob j ekte verwendet und retourniert den Inhalt des 
gewlinschten Kommunikationsob j ekts , falls dieses bereits 
definiert ist (d.h. in einer Transaktion geschrieben wurde). 
Falls das Kommunikationsob j ekt noch undefiniert ist und ein 
blockierendes Kennzeichen-Bit, das BlockingFlag , gesetzt 
ist, wartet der Befehl, bis das Ob j ekt beschrieben wird, 
ansonst retourniert er eine Fehlermeldung. 

Auch falls der ProzeB nicht berechtigt ist, auf das Ob j ekt 
OID zuzugreifen, erfolgt eine Fehlermeldung. 

Falls jedoch das Ob j ekt definiert und zugreifbar ist, wird 
sein Wert retourniert; ansonst wird, falls das Kennzeichen 
"BlockingFlag 1 ' gesetzt ist, die Lese-Anfrage an das Ob j ekt 
angehSngt, wo sie automatisch aufgeweckt wird, sobald das 
Ob j ekt beschrieben wird. 

Es hangt von der jeweiligen Verteilungsstrategie und ihren 
Flags ab, ob es bei einer Leseanf orderung ausreicht, die 
lokale Objektstruktur zu testen, oder ob Kommunikations- 
schritte durchgeflihrt werden miissen, die andere Agenten nach 
dem Zustand und Wert des Ob j ekts befragen. 

Im einzelnen wird beim "Objekt-Lesen" gemaS Fig. 7 einleitend 
bei 50 abgefragt, ob der ProzeB auf das Ob j ekt zugreifen 
darf, und ob das Ob j ekt von write-once-Typ ist. Wenn das Ab- 
f rageergebnis negativ ist, erfolgt bei 51 eine Fehlermel- 
dung, wenn das Ergebnis jedoch positiv ist, dann wird bei 52 
abgefragt, ob der Objektstatus definiert ist. Wenn ja, wird 
bei 53 der Wert des Ob j ekts retourniert, und es wird zum 
Ende der Funktion (bzw. Block 41 in Fig. 5) weitergegangen. 
Wenn jedoch der Objektstatus nicht definiert ist, wird bei 
54 abgefragt, ob blockierend gelesen wird (d.h. ob das 
BlockingFlag gesetzt ist), und wenn nein, erfolgt bei 55 
eine Fehlermeldung; wenn ja, wird im Schritt 56 weiters 
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abgefragt, ob der Request vom Benutzer aufgerufen wurde, was 
bedeutet, daB fur diesen Lese-Request noch keine Lese- 
Request-Struktur existiert. Bei negativem Ergebnis wird zum 
Schritt 41 weitergegangen; bei positivem Abf rageergebnis 
wird jedoch gemaB Block 57 eine Read-Request-Struktur 
angelegt, die dann an das Objekt angehangt wird. Danach wird 
gemaB Block 58 der Strategiemanager aufgerufen, um die 
Funktion, daB das Objekt gelesen werden soli, auszuftihren. 
Dieser Schritt 58 wird nachstehend anhand der Fig, 34 noch 
naher erlautert werden. 

Alternatives Warten : FiredOID <- alt_wait ( ListOf OlDs ) 

(s. Fig. 8) 

Dieser Befehl wird fur nicht aktualisierbare Kommunikations- 
objekte verwendet und wartet wie ein blockierendes Lesen auf 
eine Gruppe von Kommunikationsobjekten . Sobald eines dieser 
Kommunikationsobjekte aus der Liste ListOf OIDs definiert 
ist, retourniert der Befehl die entsprechende OID-Nummer des 
Objekts. Damit kann bequem (und ohne "busy-waiting" ) eine 
Synchronisation mehrerer Kommunikationsobj ekte programmiert 
werden . 

Falls eines der in der Liste (ListOf OIDs) bezeichneten 
Objekte nicht existiert Oder nicht vom write-once-Typ ist, 
oder der Prozefi nicht berechtigt ist, auf eines dieser 
Objekte zuzugreifen (s. Block 59), erfolgt - gemaB Schritt 
60 - eine Fehlermeldung. 

Fur jede OID aus der Liste ListOfOIDs gilt, daB - falls das 
durch die OID bezeichnete Objekt definiert ist (Abf rage 61), 
- dieses Objekt als das "gefeuerte Objekt" retourniert wird 
(bzw. sein Listenindex ) , s. Block 62 in Fig. 8. 
Falls kein Objekt aus der ListOf OIDs-Liste definiert ist, 
wird an jedes Objekt (d.h. an seine vom lokalen Agenten - 
21, 22 oder 23 gemaB Fig. 2 - verwaltete Objektstruktur ) aus 
dieser Liste, falls gemaB Abfrage 63 der Request vom 
Benutzer aufgerufen wurde, eine "alt_wait M -Anf rage angehangt 
(Schritte 64 bis 67, Fig.8). 

Dabei wird bei 64 ein "Alternatives Warten" -Request erzeugt, 
bei 65 wird das nachste Objekt 0 aus der Warteliste 
(ListOfOIDs) definiert, und bei 66 wird abgefragt, ob dieses 
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Objekt O leer 1st;; wenn nein, wird der H alt_wait M -Request an 
das Objekt O angehSngt (Schritt 67). Sodann wird der 
Strategiemanager informiert, daB das Objekt O gelesen werden 
soli, s. Schritt 58 (der wie erwShnt nachfolgend anhand der 
Fig. 34 noch naher erlSutert werden soil). Die Schritte 65 
bis 67 und 58 werden fOr alle Objekte der Liste wiederholt. 
Sobald ein Objekt aus der Liste ListOfOIDs definiert (d.h. 
in einer Transaktion geschrieben) wurde, wird automatisch 
diese Anfrage erfiillt, die Nummer des Objekts in der Liste 
retourniert und die Anfrage am aktuellen Objekt sowie alle 
Anfragen, die an den anderen Objekten hangen, entf ernt . 

Der Ablauf der Transaktionskontrolle ergibt sich allgemein 
aus dem Schema , Block 41, von Fig. 9, wobei der jeweils 
eingelangte Request R nun im Zusammenhang mit eventuell in ihm 
enthaltenen Transaktions-Bef ehlen untersucht wird. Dabei wird 
einleitend bei 68 abgefragt, ob eine Top- Level -Transaktion 
gestartet werden soli, und wenn ja, wird dies gemaB Block 69 (s. 
nachfolgend Erlauterung zu Fig. 10) durchgef Iihrt ; wenn nein, wird 
bei 70 abgefragt, ob eine Unter-Transaktion gestartet werden 
soil, und wenn ja, wird dies gemSB Block 71 (s. Fig. 11) durch- 
gef uhrt; wenn nein, wird bei 72 abgefragt, ob ein schwaches 
Transaktions-Kommit erfolgen soil; wenn ja, wird das schwache 
Transaktions-Kommit gemaB Block 73 (s. Fig. 12, in Verbindung mit 
Fig. 13) durchgef iihrt; wenn nein, wird nach einem Transaktions- 
Kommit mit eventuellem Abbruch abgefragt, s. Block 74 in Fig. 9; 
wenn das Ergebnis ja ist, wird das Transaktions-Kommit gemSB 
Block 75 durchgef uhrt , welches ebenfalls, zusammen mit dem 
schwachen Transaktions-Kommit, in Fig. 12 veranschaulicht ist. 
Falls der Request R kein Transaktions-Kommit-Request ist, wird 
als nachstes bei 76 abgefragt, ob ein Abbruch einer Transaktion 
gewiinscht wird, und wenn ja, wird dieser Transaktions- Abbruch 
gemaB Block 77 (s. auch Fig. 14) durchgef iihrt ; wenn nein, wird 
als nMchstes bei 78 abgefragt, ob der Request eine Transaktions- 
Rucknahme betrifft, und wenn ja, wird diese Rvicknahme gem&B 
Block 79 (s. auch Fig. 15) durchgef iihrt ; im anderen Fall wird bei 
80 abschliefiend abgefragt, ob der Request eine Riicknahme eines 
transaktionalen Befehls betrifft, und wenn ja, wird bei 81 diese 
Request-Rucknahme durchgefuhrt (s. auch Fig. 16); wenn nein, wird 
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ebenso wie nach Durchfiihrung der einzelnen Transaktions- 
Funktionen 69, 71, 73, 75, 77,^79 Oder 81 zum Block 42 in Fig. 4 
weitergegangen, bei dem es sicH\ um die nachstehend anhand der 
Fig. 17 nSher erlauterten transaktionalen Befehle handelt. 

Zuvor sollen jedoch noch di«* einzelnen Transaktions-Bef ehle, 
69, 71, 73, 75, 77, 79 oder 81 eSnhand der Fig. 10, 11, 12 (mit 
13), 14, 15 und 16 naher erlautpt werden. 

- Start einer Top-Level-Trarisaktion: TID <- top_trans_begin 

(s. Fig. 10) 

Mi-t dieser Funktion wird eine neue Top-Level-Transaktion 
angelegt und ihre eindeutige Identifizierungsnummer (TID) 
retourniert . Die TID wird als Argument an andere Befehle 
weitergegeben . 

Im einzelnen wird bei dieser Funktion im Schritt 82 eine 
eindeutige TID erzeugt und eine durch diese TID eindeutig 
gekennzeichnete Transaktionsstruktur angelegt, in der 
vermerkt ist, daB es sich um eine Top-Level-Transaktion 
handelt (d.h. sie besitzt keine Vater-Transaktion ) . Der 
Ausf lihrungszustand von TID wird auf gestartet ( "STARTED" ) 
gesetzt. Sodann wird bei 83 abgefragt, ob der Transaktions- 
Start liber das Applikations- Interface (API) des lokalen 
Sof twaresystems aufgerufen wurde; wenn ja, wird der 
Transaktions-Typ als normal definiert (Schritt 84); wenn 
nein, wird der Transaktions-Typ als Hilf stransaktion 
festgelegt (Schritt 85). In beiden Fallen wird anschlieSend 
die TID retourniert (Schritt 86). 



- Start einer ( Unter- ) Transaktion : (TID, MsgNr ) <- trans_ 
begin(TID vater ) (s. Fig. 11) 
Diese Funktion, Block 71 in Fig. 11, dient dazu, eine neue 
geschachtelte Untertransaktion anzulegen; retourniert wird 
ihre TID sowie eine eindeutige Kennzeichnung dieses Unter- 
transaktions-Bef ehls . ( Genaugenommen ist trans__begin auch 
ein transaktionaler Befehl.) Das Argument TID vater muB eine 
gviltige TID enthalten, in der diese Transaktion als Unter- 
transaktion gestartet wird, und dies wird bei 87 einleitend 
abgefragt. TID vater ist abhangig vom Erfolg von TID und 
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umgekehrt muS TID abgebrochen werden, wenn T lD vater nicht 
gutgeht. Da die Isolationseigenschaft von Transaktionen 
aufgelost wurde, kann TID kpmmitten, bevor TID V ater ferti 9 
ist. Sollte jedoch TID vat _ e3 J, danach f ehlschlagen, wird TID 
kompensiert . \ 

Im wesehtlichen lSuft die Pi^ozedur wie bei top_trans_begin 
ab, nur daB in der TransaktiJonsstruktur vermerkt wird, daS 
TID vater die Vater-Transaktiron von TID ist. 

Abgesehen von xiet; Ab^age/fiach einer TID vat;er -Transaktion 
wird bei 87 auch viberpruft, ob diese TID vater -Transaktion im 
Zustand gestartet ( "STARTED 11 ) ist, oder ob sie nicht 
gutgegangen ist ("FAILED"). Wenn das Abf rageergebnis bei 87 
negativ ist, wird im Schritt 88 eine Fehlermeldung 
abgegeben. Ansonsten wird im Schritt 89 eine eindeutige TID 
erzeugt, die zugehorige Transaktions-Struktur angelegt, der 
Transaktions-Vater (TID vater ) definiert, der 

Ausf uhrungszustand der Transaktion auf gestartet ( "STARTED" ) 
gesetzt und der Transaktions-Typ als normal definiert. 
AnschlieSend werden bei 90 die TID und die eindeutige 
Nachrichtennummer retourniert, und danach wird - ebenso wie 
im Fall der Fehlermeldung gemaB Schritt 88 - zum Block 42 
(Fig. 4) weitergegangen. 

Schwaches Transaktions-Kommit : Result <- trans_try_ 
commit ( TID ) 

und 

Transaktions-Kommit : Result <- trans__commit ( TID ) (s. Fig. 12) 
Beim Start des schwachen Transaktions-Kommits (d.i. eine 
Kommit-Aktion ohne Abbruch ) einer Transaktion TID wird 
(ebenso wie beim " starken" oder bedingungslosen Trans- 
aktions-Kommit, bei dem gegebenenf alls ein Abbruch erf olgt ) 
die Ausfuhrung aller transaktionalen Befehle bewirkt, die in 
dieser Transaktion angegeben wurden; wenn nur einer dLieser 
Befehle nicht ausfuhrbar ist, kann das Kommit nicht gutge- 
hen, und es wird als Ergebnis hiervon die Nummer des 
f ehlgeschlagenen Befehls retourniert. Ansonst werden, wenn 
das Kommit erfolgreich ist, die Effekte aller Befehle atomar 
sichtbar gemacht und alle spezif izierten Kommit-Aktionen 
angestartet; weiters wird eine Erf olgsmeldung retourniert. 
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Wenn die Prozedur fur ein ( Schwaches ) Transaktions-Kommit 
vom Benutzer aufgerufen wird, dann darf ferner die 
Transaktions-Identifikation TID keine Hilfstransaktion 
bezeichnen . 

Im einzelnen wird, wenn die Transaktion, die durch TID 
bezeichnet wird, nicht existiert, oder wenn ihr Ausf vihrungs- 
zustand nicht "STARTED" oder "FAILED" ist, oder wenn der 
ProzeB nicht berechtigt ist, auf die in den transaktionalen 
Anfragen verwendeten Objekte zuzugreifen (s. Abf rage-Block 
91 in Fig. 12), eine Fehlermeldung (Schritt 92 in Fig. 12) 
erzeugt. Uberdies wird der Ausf uhrungszustand der 
Transaktion auf " COMMITTING" gesetzt (s. Block 93). 
Sodann wird - gemaB Block 94 - die Strategie der Transaktion 
aufgrund der in ihr abgesetzten Anfragen bestimmt bzw. uber- 
pruft, d.h. die Strategien aller in dieser Transaktion von 
Schreib-Anfragen geschriebenen Objekte, aller von 
cobj_trans_read (s. unten ) gelesenen Objekte, aller Objekte, 
die als PIDs oder in Eintragen in den nachstehend 
erlauterten Anfragen dep_process, compensate_action und 
on_commit_action dienen, sowie die Strategien aller 
Untertransaktionen mussen dieselbe Zuverlassigkeitsklasse 
haben und derselben Basis-Strategie angehoren. Falls dies 
nicht zutrifft, wird wiederum eine Fehlermeldung erzeugt (s. 
Block 92 ) . 

Nun wird versucht, jede transaktionale Anfrage dieser 
Transaktion zu erfullen. Dabei werden gegebenenf alls alle 
transaktionalen Anfragen (Requests) R der Reihe nach in 
einer Schleife 95 mit dem Eingangsschritt 96 (in dem immer 
auf den nachsten Request weitergeschaltet wird) behandelt, 
bis die Liste der Requests abgearbei tet , d.h. leer ist 
(Abf rage 97), wobei dann auf eine Prozedur "Transaktions- 
Kommit beenden" (s. Block 98 bzw. Fig. 13) ubergegangen wird. 

Solange noch Requests vorliegen, d.h. R nicht leer ist 
(Abf rage 97), passiert folgendes: 

Wenn es sich bei R urn eine Untertransaktion handelt (Abf rage 
99), dann muB die Anfrage terminiert (Abf rage 100) und 
erfolgreich "committed" haben (Abfrage 101); ansonst wird 
eine Fehlermeldung erzeugt (Block 92). 



- 27 - 



Wenn die Anfrage R eine Schreib-Anfrage 1st: (Abfrage 102), 
so wird sie an die Objektstruktur des zu schreibenden 
Objekts OID angehSngt (Block 103); und es wird versucht, das 
Objekt zu beschreiben (Block 104); diese Prozedur wird 
nachstehend anhand der Fig. 23 erlautert werden, hier genUgen 
vorerst folgende Erlauterungen: es wird die entsprechende 
Verteilungsstrategie aufgerufen, um eine exklusive Sperre 
auf OID zu bekommen (d.h. die "Hauptkopie" bei Replikations- 
protokollen ) ; falls die OID bereits von einer anderen Trans- 
aktion gesperrt ist und die sperrende Transaktion jiinger als 
die vorliegende Transaktion TID ist, mufi die jungere Trans- 
aktion die Sperre temporar fur TID freigeben ( 11 Deadlock' 1 — 
Vermeidung ! ) ; die Anfrage der jungeren Transaktionen wird 
autoraatisch spater wieder aufgeweckt; wenn die OID bereits 
definiert ist und es sich um ein nur einmal beschreibbares 
Objekt handelt, erfolgt eine Fehler-Meldung; ansonst wird 
das Objekt mit der Nr. OID nun fur TID gesperrt und provi- 
sorisch wird der Wert in OID geschrieben (d.h. er ist noch 
nicht offiziell sichtbar); dabei sind alle bisher in der 
Transaktion TID angemeldeten Schreib-Anf ragen bereits zu 
beriicksichtigen; Kommunikationsob j ekte f die in einem iiber- 
schriebenen Wert eines aktualisierbaren Objekt s vorkommen, 
werden protokollabhangig der Garbage-Collection (s. Fig. 40) 
unterworfen, sofern ihr Ref erenzzahler 0 geworden ist; 
Wenn der Request einen abhangigen ProzeS betrifft (der 
nachfolgend anhand von Fig ,25 noch naher erlautert wird), 
d.h. eine dep_process- Anfrage ist, was mit der Abfrage 105 
in Fig. 12 festgestellt wird, so wird im Schritt 106 ein 
entsprechender dep_process-Request angelegt, der an das PID- 
Objekt des Prozesses angehangt wird, und danach wird dieser 
transaktionale Request wieder im Block 104 (s. Fig. 23) 
behandelt; dabei wird gewartet, bis diese dep_process- 
Anfrage terminiert hat. Falls der Ausf uhrungszustand dieser 
Anfrage nicht " PREPARED " oder "CANCELLED" ist, erfolgt eine 
Fehlermeldung . 

Wenn die Anfrage R eine Anfrage fur transaktionales Lesen 
(s. Fig. 19), d.h. ein cobj_trans_read-Request ist, was bei 
107 in Fig. 12 abgefragt wird, dann wird diese Anfrage (gemSB 
Schritt 108) an die Objektstruktur des zu schreibenden 
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Objekts OID angehangt, und es wird wieder zur Prozedur gemSLB 
Block 104 ubergegangen (s. Fig. 23), wobei dort die 
entsprechende Verteilungsstrategie aufgerufen wird, urn eine 
exklusive Sperre auf das Objekt OID zu bekommen (vgl. oben 
den Vorgang bei Schreib-Anf ragen ) ; es wird dann getestet, ob 
der gelesene Wert noch immer aktuell ist; falls nicht, oder 
falls bereits anfanglich der trans_cobj_read-Befehl 
fehlgeschlagen hat, erfolgt eine Fehlermeldung. 

Sobald, wie oben beschrieben, alle Anf ragen erfolgreich 
durchgef iihrt wurden (Abfrage R ist leer, Block 97), wird die 
Prozedur " Transaktions-Kommit Beenden" Block 98 (s. Fig. 13) 
aufgerufen; es darf keine Sperre mehr zugunsten einer 
anderen Transaktion aufgegeben werden; alle Effekte (in 
Objekte geschriebenen Werte ) werden nun in einem Schritt 
(atomar) sichtbar gemacht; dazu gehort auch das Anstarten 
aller "on_commit_action"-Befehle dieser Transaktion 
(dieselbe Prozedur wie das Anstarten eines - noch zu 
beschreibenden - unabhangigen Prozesses ) und das Schicken 
eines Signals " COMMIT M an alle dep_proces s - Prozeduren dieser 
Transaktion- Die Zuverlassigkeit der Effekte der Transaktion 
hangt von der jeweiligen Verteilungsstrategie der 
Transaktion ab. 

Falls die Transaktion eine Top-Level-Transaktion war, kann 
nun ihre Transaktionsstruktur entfernt werden (was in Fig. 12 
der Einfachheit halber nicht dargestellt ist). Ansonst wird 
ihr Ausf uhrungszustand auf "COMMITTED" gesetzt, und sie muB 
aufgehoben werden, bis ihre Vater-Transaktion terminiert, da 
bis dahin Kompensations-Aktions-Prozeduren noch ben6tigt 
werden. Wenn es sich um eine Hilf stransaktion handelt, wird 
nun das Beenden (exit) des entsprechenden unabhangigen 
Prozesses aufgeweckt. 

Der Aufruf der Verteilungsstrategie, um eine exklusive Sper- 
re zu bekommen, muB nicht sofort erfolgreich sein, sondern 
kann eine Reihe von Kommunikationsschritten verlangen. 
Sobald eine Entscheidung vorliegt, wird wieder automatisch 
der Transaktionsmanager aktiviert, um das Kommit (Fig. 12) 
f ortzusetzen . 

Eine Fehlermeldung - s. Block 92 in Fig. 12 - bei der Ausfiih- 
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rung von transaktionalen Anfragen bedeutet nicht, daB die 
Transaktion abgebrochen ( "aborted" ) wird; im Falle eines 
schwachen Transaktions-Kommit (Abfrage 109) wird der AusfUh- 
rungszustand der Transaktion auf "FAILED" gesetzt (Schritt 
110), und die Nachrichtennummer (MsgNr) der Anfrage, die die 
Fehlermeldung verursacht hat, ist abfragbar; diese Anfrage 
kann mit dem Befehl "cancel" zuruckgenommen werden, und es 
kann wiederholt versucht werden, die Transaktion zu 
kommitten . 

Falls die Strategie der Transaktion eine "zuverlSssige" 
Strategie ist, so liberleben die Effekte der Transaktion auch 
Systemf ehler . 

Wenn sich bei der Abfrage 109 ergibt, daS ein "starkes" 
Transaktions-Kommit betroffen ist, so verhalt sich diese 
Funktion trans_commit wie die vorhergehende schwache 
Transaktions-Kommit-Funktion ( trans_try_commit ) mit dem 
Unterschied, daB dann, wenn das Kommit nicht erfolgreich 
ist, die Transaktion TID automatisch abgebrochen wird, s. 
Block 77 in Fig. 12, *' Transaktions- Abbruch " ( " trans_abort " ) , 
der in Fig. 14 naher veranschaulicht ist. 

Bevor nun der Abbruch einer Transaktion anhand der Fig. 14 
naher erlautert wird, sei noch auf die Prozedur 
" Transaktions-Kommit-Beenden" (s. Block 98 in Fig. 12) anhand 
der Fig. 13 eingegangen. 

Bei dieser Prozedur wird einleitend bei 111 abgefragt, ob 
alle transaktionalen Anfragen der Transaktion bereits 
erledigt wurden; wenn nein, wird sofort zum Ausgang dieser 
Prozedur (und beispielsweise zum Block 42 in Fig. 4) 
ubergegangen . Wenn das Abf rageergebnis bei 111 jedoch 
positiv ist, wird bei 112 der Recoverymanager aufgerufen, um 
den atomaren Schritt START durchzuf uhren . Danach wird die 
nachste Anfrage aus der Liste transaktionaler Request der 
Transaktion aufgegriffen (Schritt 113), und bei 114 wird 
abgefragt, ob es noch einen Request R in der Liste R gibt. 
Falls R nicht leer ist, d.h. solange transaktionale Anfragen 
vorhanden sind, wird sodann bei 115 abgefragt, ob der 
Request das Anlegen einer Untertransaktion betrif f t ; wenn 
ja, wird zum Schritt 113 zuruckgekehrt ; wenn nein, wird 
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sodann bei 116 abgefragt, ob ein transaktionaler Befehl 
M Objekt-Schreiben" vom Request betroffen 1st. Wenn nein, 
wird bei 117 abgefragt, ob der Request einen unabhSngigen 
ProzeS betrifft; falls ja, wird ebenfalls zum Schritt 113 
zuriickgekehrt, andernfalls wird bei 118 abgefragt, ob es 
sich bei dem Request urn den transaktionalen Befehl "trans- 
aktionales Objekt-Lesen" handelt; falls nein, wird sodann 
bei 119 abgefragt> ob diese Request den transaktionalen 
Befehl "Kommit-Aktion-Anmelden" betrifft; falls nein, wird 
nun ebenfalls zum Schritt 113 zuriickgekehrt. 
Die transaktionalen Befehle "Objekt-Schreiben" , "transak- 
tionales Objekt-Lesen" und "Kommit-Aktion-Anmelden" werden 
nachstehend anhand der Fig. 18, 19 und 21 noch naher 
erlautert werden. 

Wenn im Ablauf gemaS Fig. 13 das Ergebnis der Abfrage nach 
"Objekt-Schreiben" , Block 116, positiv ist, so wird in einem 
Schritt 120 der Wert des Objekts vorubergehend in das Objekt 
geschrieben, es wird die Zeitmarke des Objekts inkremen- 
tiert, und der Status des Objekts wird auf "definiert" 
("defined") bzw. "Referenz" ("Reference") gesetzt. im 
AnschluS daran wird bei 121 die transaktionale Prozedur 
"Objekt-Auf wecken" aufgerufen, welche nachstehend anhand der 
Fig. 22 noch naher erlautert werden soil, und es wird danach 
zum Schritt 113 zuriickgekehrt. 

Wenn sich bei der Abfrage 118 ergibt, daB der Request ein 
transaktionales Objekt-Lesen betrifft, so wird im Schritt 
122 abgefragt, ob die Zeitmarke des betroffenen Objekts 
gleich der Zeitmarke zum Zeitpunkt des Lesens ist, und falls 
dies zutrifft, wird ebenfalls die Prozedur 121 "Objekt- 
Auf wecken" aufgerufen. Wenn dies hingegen nicht der Fall 
ist, dann wird bei 123 der Recoverymanager aufgerufen, urn 
den atomaren Schritt ABBRUCH durchzuf uhren , wonach bei 124 
abgefragt wird, ob das betroffene Kommit ein schwaches Oder 
ein normales ( starkes ) Transaktions-Kommit war. Im Falle 
eines starken Transaktions-Kommits erfolgt dann gemaB Block 
77 der Abbruch der Transaktion, im Fall eines schwachen 
Transaktions-Kommits wird hingegen der Ausf uhrungszustand 
der Transaktion auf "Fehlgeschlagen" ("FAILED") gesetzt, s. 
Block 125 in Fig. 13. In beiden Fallen folgt anschlieBend 



gemaB Schritt 126 eine Fehlermeldung . 

Wenn sich bei der Abfrage 119 ergibt, daS der Request R das 
Anmelden einer Kommit-Aktion betrifft, so wird gemaB Block 
127 der Prozefimanager aufgerufen, urn einen unabhangigen 
ProzeB (wie nachfolgend anhand von Fig. 26 erlSutert werden 
soli) fur die Kommit-Aktion anzustarten. 1m AnschluB daran 
wird ebenfalls zum Schritt 113 zuruckgekehrt . 
Falls bei der Abfrage 114 festgestellt wird, daS keine 
Requests mehr vorliegen (R 1st leer), wird die zuvor 
vorgenorrimene exklusive Sperre an alien von der Transaktion 
gesperrten Objekten freigegeben, s. Schritt 128, und es wird 
ein Kommit-Signal an alle abhangigen Unter-Prozesse der 
Transaktion gesandt, Schritt 129, wonach im Schritt 130 der 
Ausfuhrungszustand der Transaktion auf "COMMITTED" gesetzt 
wird. Nach dieser erf olgreichen Vollzugsmeldung der Trans- 
aktion wird abschlieBend der Recoverymanager fur die Durch- 
ftihrung des atomaren Schritts "ENDE" aufgerufen (Block 131). 
Danach wird beispielsweise zur nachsten Prozedur (Trans- 
aktionale Befehle gemaB Block 42 in Fig. 4) ubergegangen. 

Im Ablauf gemaB Fig. 9 ist nach dem Transaktions-Kommit als 
nachste Moglichkeit wie erwahnt ein Transaktions-Abbruch 
vorgesehen, s. Block 77, und ein solcher Transaktions- 
Abbruch ist auch am Ende der Prozedur gemaB Fig. 12 
( Transaktions-Kommit ) vorzunehmen . 

Abbruch einer Transaktion: trans_abort ( TID ) (s. Fig. 14) 

Diese Funktion verursacht den Abbruch der angegebenen Trans- 
aktion TID und - falls diese Transaktion Untertransaktionen 
besitzt - rekursiv auch deren Abbruch (s. Block 77 1 in 
Fig. 14). Es ist zu beachten, daB dann, wenn eine oder 
mehrere Untertransaktion(en) bereits erfolgreich kommittet 
hat bzw. haben, ein Abbruch der Transaktion die Ausfiihrung 
der Kompensationsaktion ( en ) von solchen Untertransaktionen 
bewirkt, von der/denen angenommen wird, daB sie auch alle 
Effekte ihrer Untertransaktionen kompensiert/en, d.h. in 
diesem Fall wird nicht mehr rekursiv abgebrochen. Wenn die 
abzubrechende Transaktion TID eine Vatertransaktion besitzt, 
so kann diese nicht mehr erfolgreich kommitten, auBer die 
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Transaktion TID wird noch ausdrucklich zuruckgenonunen (mit 
Hilfe von "trans- cancel ( TID ) M , s. unten). 
Im einzelnen ist der Ablauf gemaB Fig. 14 wie folgt: 
Nach einem einleitenden Aufruf des Recoverymanagers bei 132, 
um den atomaren Schritt START auszufiihren, wird bei 133 ab- 
gefragt, ob der Ausgangszustand der Transaktion TID "FAILED" 
Oder "STARTED" ist; wenn ja, dann wird " trans_abort" auch 
fur alle Untertransaktionen dieser Transaktion TID aufge- 
rufen, und das Signal "ABORT" wird an alle abh&ngigen 
( "dep_process"- )Prozesse (s. unten), die in der Transaktion 
TID gestartet wurderi, gesendet. Dabei wird gemafi Schritt 134 
der nachste abhangige ProzeB der Transaktion mit R 
bezeichnet, und bei 135 wird abgefragt, ob noch derartige 
Prozesse vorliegen; wenn R noch nicht leer ist, wird gemafi 
Block 219 der ProzeBmanager aufgerufen, um ein Signal 
"ABORT" an die PID des Requests zu schicken ( zu "Signal 
schicken" s. auch nachstehend zu Fig. 27); wenn gemSB Abfrage 
135 keine Prozesse mehr vorliegen, d.h. wenn R ist leer ist, 
dann wird im Schritt 136 die nachste Untertransaktion der 
Transaktion mit T bezeichnet und bei 137 abgefragt, ob es 
noch eine gab. Wenn ja, wird diese Untertransaktion T gemaB 
Block 77 1 abgebrochen, und es wird zum Schritt 136 zuruck- 
gekehrt. Sobald keine Untertransaktionen mehr vorliegen 
(Ausgang J der Abfrage 137), wird gemaB Schritt 138 der 
Ausgangszustand der Transaktion TID auf "abgebrochen" 
( "ABORTED" ) gesetzt. 

Wenn sich nach einem negativen Abf rageergebnis bei 133 in 
einer Abfrage 139 der Ausgangszustand der Transaktion TID 
als "COMMITTED" ergibt, dann werden gemaB Schritt 140 
(Definition von nachstem R); Abfrage 141 ("Liste R leer ?") 
und Block 142 (Start eines unabhangigen Prozesses ) alle 
Kompensationsaktionen dieser Transaktion TID aktiviert 
(dieselbe Prozedur wie das Anstarten eines unabhangigen (= 
INDEP- (Prozesses ) . 

Wenn andererseits der Ausgangszustand der Transaktion TID 
nicht " COMMITTED " (Block 139), jedoch gemaB Abfrage 143 
"COMMITTING" ist, dann sind alle transaktionalen Anfragen 
der Transaktion aufzufinden, die von der Kommit-Aktion an 
Objekte gehangt wurden, und dort zu entfernen. Auch sind 



- 33 - 



mogliche durch die Transaktion TID verursachte Objektsperren 
zuruckzusetzen (Schritt 144). Sodann wird die Prozedur 
"Objekt-Aufwecken" 121 (s. Fig. 22) aufgerufen, um alle von 
der Transaktion gesperrten Objekte aufzuwecken. Sodann wird 
der Zustand der Transaktion auf "abgebrochen" ("ABORTED") 
gesetzt, und die Transaktionsstruktur kann nun entfernt 
werden (Schritt 138). GemaB Schritt 121 1 wird anschlieSend 
wieder die Prozedur "Objekt-Aufwecken" aufgerufen (Fig. 22), 
um die PID des Prozesses der Transaktion aufzuwecken. Danach 
wird bei 145 der Recoverymanager aufgerufen, um den Atomaren 
Schritt ENDE auszufuhren. Zu diesem Schritt 145 gelangt man 
auch, wenn bei der Abfrage 143 festgestellt wurde, daB der 
Zustand der Transaktion nicht "COMMITTING" ist. 

Riicknahme einer Transaktion: trans_cancel ( TID ) (s. Fig. 15 
bzw. Block 79 in Fig. 9) 
Dieser Request verhalt sich wie "Transaktions-Abbruch" 
( "trans-abort (TID) " ) , (s. oben bzw. Block 77 in Fig. 14) mit 
dem Unterschied, daB der Erfolg einer umschlieBenden Vater- 
transaktion davon nicht betroffen ist. Wenn also nach dem 
START-Schritt 146 bei der Abfrage 147 festgestellt wird, daB 
die betroffene Transaktion TID keine Top-Level-Transaktion 
ist, dann wird gemSB Schritt 148 die trans_begin( TID vater ) - 
Anfrage aus der Liste der transaktionalen Anfragen ihrer 
Vater-Transaktion entfernt. Danach - oder wenn die Trans- 
aktion eine Top-Level-Transaktion ist (Abfrage 147) - folgt 
die Abbruch-Transaktion, Block 77, gefolgt vom Beendigungs- 
schritt 149. 

Rucknahme eines transaktionalen Befehls: cancel (TID, MsgNr) 
(Block 81 in Fig. 9, s. Fig. 16) 
Der letzte Block im Ablauf von Fig. 9 betrifft eine etwaige 
Requestrucknahme (Block 81), wobei in diesem Fall, gemaB 
Fig. 16, einleitend bei 150 nach dem Zustand der Transaktion 
abgefragt wird; sofern dieser Zustand STARTED oder FAILED 
ist, wird der Request mit der angegebenen Nummer von der 
Transaktion TID entfernt, s. Schritt 151 in Fig. 16. Sofern 
der Zustand der Transaktion nicht STARTED oder FAILED ist, 
wird gemaB Schritt 152 eine Fehlermeldung abgegeben. 
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Es wird somit gemaB Fig. 16 der durch die Nachrichten-Nummer 
"MsgNr" spezif izierte transaktionale Befehl bzw. Request; 
zuriickgenommen. (Betrif ft dieser Befehl das Anlegen einer 
Untertransaktion , so hat "cancel" denselben Effekt wie 
"trans__cancel", s. oben, und analog fur abhangige Prozesse 
denselben Effekt wie " signal_( CANCEL ) " , s. unten; dies ist 
jedoch der Einfachheit halber in Fig. 16 weggelassen worden. ) 

Wenn nun wieder zu Fig. 4 zuriickgekehrt wird, so ergibt sich 
aus dem dortigen Ablauf im AnschluB an Block 41, Befehl zur 
Transakt ionskontrol le , der Block 42: Transaktionaler Befehl. Der 
Ablauf dieser Funktion 42 ist in Fig. 17 naher veranschaulicht , 
wobei ersichtlich ist, daS einleitend abgefragt wird ( bei 153), 
ob es sich um einen Befehl zum Objekt-Schreiben handelt. Wenn 
ja, wird die Prozedur "Objekt-Schreiben" gemaB Block 154 
aufgerufen, wobei dieser transaktionale Befehl Objekt-Schreiben 
nachfolgend anhand der Fig. 18 naher erlautert werden soil. 

Wenn kein Befehl zum Beschreiben eines Objekts vorliegt, 
wird anschlieBend bei 155 abgefragt, ob ein Befehl zum trans- 
aktionalen Lesen vorliegt. Wenn ja, wird gemaB Block 156 die 
Prozedur " transaktionales Objekt-Lesen" aufgerufen, die nachfol- 
gend anhand der Fig. 19 beschrieben werden wird. Wenn nein, wird 
als nachstes bei 157 abgefragt, ob der Request einen abh&ngigen 
ProzeB betrif f t . * Wenn ja, wird bei 158 der Prozefimanager aufge- 
rufen, um den abhangigen ProzeB anzustarten; die entsprechende 
Prozedur ( "dep_process-START" ) wird nachfolgend im Rahmen des 
ProzeSmanagers noch naher erlautert werden. 

Wenn kein abhangiger ProzeB zu behandeln ist, wird im 
Schritt 159 abgefragt, ob der Request das Anmelden einer 
Kompensations-Aktion betrif ft, und wenn ja, folgt gemaB Block 
160 die Prozedur "Kompensations-Aktion Anmelden" ( welche 
nachfolgend anhand der Fig. 20 naher erlautert werden wird). Wenn 
nein, wird schlieBlich bei 161 abgefragt, ob der Request das 
Anmelden einer Kommit- Aktion betrif ft, und wenn ja, folgt gemSB 
Block 162 die nachfolgend anhand der Fig. 21 zu erlauternde 
Prozedur " Kommit-Aktion-Anmelden" . 

Im einzelnen sind die vorstehend bereits angesprochenen 
transaktionalen Befehle (s. Fig. 17) noch f olgendermaSen zu 
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erlSutern . 

- Anmelden des Beschreibens eines Objekts: MsgNr <- 

cobj_write( TID, OID, Value) (s. Block 154 in 

Fig. 17; Fig. 18) 
Mit diesem Befehl wird innerhalb einer Transaktion TID das 
Schreiben eines Wertes ("Value") - s. Block 163 in Fig. 18 - 
in ein Kommunikationsob jekt OID angemeldet. Das Schreiben 
wird aber erst beim erf olgreichen Transaktions-Kommit 
ausgefuhrt (s. vorstehende Ausfuhrungen zu Fig. 12 und 13). 
Retourniert wird gemaB Schritt 164 eine lokal eindeutige 
Nachrichten-Nummer ("MsgNr"), mit der man sich im folgenden, 
z.B. zum Rucksetzen, auf diesen Schreibebef ehl beziehen 
kann . 

Es wird im einzelnen mit diesem Befehl eine transaktionale 
Anf ragestruktur generiert, die besagt, daB der Wert 
( "Value" ) in das Kommunikationsob j ekt OID geschrieben werden 
soil, und diese Anf ragestruktur an die durch TID 
gekennzeichnete Transaktionsstruktur angehangt . 

- Transaktionales Objekt-Lesen : (Value, Time2, MsgNr) <- 

trans_cobj_read( BlockingFlag, OID, TID, Timel ) 

(s. Block 156 in Fig. 17; Fig. 19) 
Dieser Befehl wird fur aktualisierbare Kommunikationsob jekte 
verwendet und verhalt sich ahnlich wie "Objekt-Lesen" 
( "cobj^read"; s. oben zu Fig.7), wobei mit einer logischen 
Zeitmarke ("Timel") sichergestellt wird, daB der zu lesende 
Wert neuer als diese Zeitmarke sein muB . Andernfalls wird, 
abhangig vom BlockingFlag, entweder eine Fehlermeldung 
retourniert oder blockiert. 

Es kann ( im Unterschied zu "Objekt-Lesen") in dem Fall, daB 
ein BlockingFlag gesetzt ist, gewartet werden, bis die Zeit- 
bedingung erfiillt ist, wobei dann neben einer lokal eindeu- 
tigen Kennung des Lesebefehls (= MsgNr) auch der aktuelle 
Wert von OID ( "Value" ) sowie eine logische Zeitmarke 
("Time2 ,, ) des gelesenen Werts retourniert wird. Wenn ein 
BlockingFlag nicht gesetzt ist und die Zeitbedingung erfiillt 
ist, dann werden dieselben Daten wie beschrieben retour- 
niert, ansonst kommt es zu einer Fehlermeldung, und es wird 



vermerkt, daB das Lesen nicht gutgegangen ist. 
Die Transaktion TID prtif t ; nach einem erf olgreichen Lesen 
beim Transaktions-Kommit ; ! pb die Zeitmarke Time2 noch immer 
dem aktuellen Wert des Objekts entspricht, und macht den 
Erfolg des Kommits davon abhangig. 

Die deri Lesebefehl eindeuti^ identifizierende Nummer 
( "MsgNr" ) kann spater zum Rpcksetzen des Befehls verwendet 
werden. Analog zu "alt_waitr' (s. Fig. 8) gibt es auch einen 
transaktionaliervlfief^hl iyr aktualisierbare Kommunikations- 
objekte, der ebenfalls^Zeitmarken verwendet:. 

Im einzelnen wird gemaB Fig. 19 beim Transaktionalen Objekt- 
Lesen einleitend abgefragt (Schritt 165), ob der Lese- 
Request bereits beantwortet wurde; wenn ja, wird sofort zum 
Ausgang (z.B. zu 43 oder 215) der Prozedur 156 ubergegangen; 
wenn nein, wird nachfolgend bei 166 abgefragt, ob eine 
Berechtigung fur den ProzeS gegeben ist, auf das Objekt 
zuzugreifen; falls dies nicht zutrifft, wird gem&S Schritt 
167 eine Fehlermeldung abgegeben, und es wird ebenfalls zum 
Ausgang der Prozedur 156 ubergegangen. Wenn die Berechtigung 
jedoch gegeben ist, wird sodann abgefragt, ob der Request: 
vom Benutzer aufgerufen wurde (was bedeutet, daB noch keine 
transaktionale Lese-Request-Struktur an der Transaktion fur 
diese Leseanf orderung existiert ) . Wenn der Request: vom 
Benutzer aufgerufen wurde, so wird anschliefiend im Schritt 

169 der Zustand des Objekts abgefragt, d.h. es wird 
abgefragt, ob der Zustand "definiert" ("DEFINED") ist, und 
weiters wird abgefragt, ob die Ob j ekt-Zeitmarke alter, d.h. 
grofier, ist als die Wert-Zeitmarke ( Timel ) . Wenn sich jedoch 
bei der Abfrage 168 ergibt, daB noch keine transaktionale 
Lese-Request-Struktur existiert, wird eine solche im Schritt 

170 erzeugt und an die Transaktion angehangt, worauf 
ebenfalls zur Abfrage 169 ubergegangen wird. 

Wenn sodann das Ergebnis der Abfrage 169 positiv ist, wird 
gem&6 Schritt 171 die Zeitmarke Time2 des Lesezeitpunkts am 
Objekt vermerkt, und es werden weiters der Wert ("Value"), 
die bereits erwahnte eindeutige Nachrichtennummer (MsgNr) 
und die Wert-Zeitmarke Time2 retourniert. Danach wird zum 
Ausgang der Prozedur 156 ubergegangen. 

1st hingegen das Ergebnis der Abfrage bei 169 negativ, so 
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wird bei 172 weiter abgefragt, ob blockierend gelesen wird 
(d.h. ob das vorerwahnte BlockingFlag gesetzt ist), und wenn 
nein, erfolgt gemaB Schritt^ 167 eine Fehlermeldung; wenn 
jedoch ja, wird der Strateglemanager aufgerufen, um die 
Prozedur "Objekt soil gelesen werden", Block 58 (s. auch 
Fig. 34) durchzufiihren. ) 

DEP-ProzeB-Start : Generieren^ einer lokalen ProzeBstruktur 

( s; B-ljQCpk^ 158 ip<Fig. 17 ) : MsgNr <-dep_process(TID, 
PID, LSYS, Si^e, Entry) (s. Fig. 25) 
Diese Prozedur ist eigentlich dem Prozeflmanager zuzuordnen, 
wenngleich sie auch als Transaktionaler Befehl behandelt 
werden kann (s. Fig. 17) und demgemaB hier in der 
Beschreibung vorgezogen werden soil. 

Ganz allgemein wird nach Uberprufung von TID, PID, Entry und 
Site wie bei "indep_process" (s. unten bzw. Fig. 26) eine 
neue ProzeBstruktur erzeugt, falls der ProzeS (mit der 
Nummer PID) auf dem lokalen Rechner (= "Site") laufen soil, 
und der ProzeB wird lokal angestartet, ansonst wird die 
Verteilungsstrategie von PID aufgerufen, um den ProzeB an 
den mit "Site" spezif izierten Rechner zu schicken. 
Welters wird eine transaktionale Anf ragestruktur generiert, 
die besagt, daB ein abhangiger ProzeB gestartet wurde, und 
diese transaktionale Anf ragestruktur wird an die durch TID 
gekennzeichnete Transaktionsstruktur angehangt . Eine lokal 
eindeutige Nummer wird retourniert, die zum Rucknehmen des 
Befehls verwendet werden kann. 

Eine Transaktion TID kann nur dann erf olgreich kommitten, 
wenn alle ihre abhangigen Unterprozesse erfolgreich 
terminiert haben. 

Eine Hilf stransaktion wird generiert, die als die Transakti- 
on dieses Prozesses in seiner ProzeBstruktur vermerkt wird. 
Im einzelnen wird gemaB dem Ablauf von Fig. 25 einleitend bei 
173 abgefragt, ob der ProzeB auf alle Objekte des abhSngigen 
Prozesses sowie auf den ProzeBidentif izierer PID zugreifen 
darf; wenn nein, erfolgt gemafl Schritt 174 eine Fehler- 
meldung, und es wird zum Ausgang der Prozedur ( etwa zu 43) 
ubergegangen. Wenn die Zugrif f sberechtigung gegeben ist, 
wird im Schritt 175 ein dep_process-Request generiert und an 
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die Transaktion angehangt, wonach bei 176 die Prozedur 
"ProzeBkreieren" aufgerufen wird, die nachfolgend anhand von 
Fig. 30 noch naher erlautert werden wird. Danach wird im 
Schritt 177 eine eindeutige Nachrichtennuramer retourniert. 



- Anmelden einer Kompensations-Aktion : MsgNr < - 

compensate_action( TID, PID, LSYS, Site, Entry ) 
(s. Fig. 20 bzw. Block 160 in Fig. 17) 
Vorweg wird hier bei 178 viberpruft, ob der aktuelle Prozefi 
mit der Nummer PID ein Zugrif f srecht auf alle in "En-try" 
vorkommenden Objekte sowie auf die PID besitzt; falls nicht, 
wird eine Fehlermeldung erzeugt (Schritt 179). 
Ansonst wird im Schritt 180 eine transaktionale Anfrage- 
struktur generiert, die besagt, daB eine Kompensationsaktion 
definiert wurde, und diese wird an die durch TID gekenn- 
zeichnete Transaktionsstruktur angehangt. Sodann wird im 
Schritt 181 eine lokal eindeutige Nummer retourniert, die 
zum Rucksetzen des Befehls verwendet werden kann. 
Kompensationsaktionen werden gestartet, wenn die Transaktion 
TID erfolgreich kommittet hat und dann abgebrochen wird. 

- Kommit- Aktion- Anmelden : MsgNr <- on_commit_action( TID, PID, 

LSYS, Site, Entry) (s. Fig. 21 bzw. Block 162 in 
Fig. 17 ) 

Im Prinzip ist dieser Befehl im Ablauf ahnlich dem Befehl 
M compensate_action" gemaB Fig. 20, nur daB die Anfrage- 
struktur besagt, daB eine Kommit- Aktion angemeldet wurde. So 
wird einleitend im Schritt 182 die Zugrif fsberechtigung des 
Prozesses betreffend die Objekte der Kommit-Aktion sowie 
betreffend die PID abgefragt, und falls keine Zugriffs- 
berechtigung gegeben ist, wird eine Fehlermeldung gemSB 
Schritt 183 abgesetzt. Ansonsten wird im Schritt 184 ein 
Kommit-Request generiert und an die betreffende Transaktion 
angehangt, wonach im Schritt 185 eine eindeutige 
Nachrichtennummer ("MsgNr") retourniert wird. 
Kommit-Aktionen werden beim "Kommit" von TID gestartet. 

Bevor nun auf die Proze8-Bef ehle (s. Block 43 in Fig . 4 ) bzw. 
auf den entsprechenden ProzeBmanager (Fig. 25 bzw. Fig. 26 und 28 
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bis 31) naher eingegangen wird, soil noch unter Bezugnahme auf 
Fig. 22 und 23 das Aufwecken eines Objekts (vgl. z.B. Block 121 
Oder 121' in Fig. 13 bzw. 14) sowie die Behandlung transaktiona- 
ler Requests (s. Block 104 in Fig. 12) naher erlautert werden. 

- Obj ekt-Auf wecken : (Fig. 22; Block 121) 

Hier wird einleitend im Block 186 R als der nfichste Request: 
des Objekts definiert, und es wird anschlieBend bei 187 ab- 
gefragt, ob R leer ist; falls nein, wird bei 188 abgefragt, 
ob R das Lesen eines Objekts betrifft; wenn ja, wird die 
Prozedur Objekt-Lesen bei Block 47 aufgerufen, und 
anschlieBend wird zum Schritt 186 zuruckgekehrt . Wenn das 
Abf rageergebnis bei 188 negativ ist, wird bei 189 abgefragt, 
ob R ein alternatives Warten betrifft, und wenn ja, wird die 
entsprechende Prozedur 49 aufgerufen, wonach ebenfalls zum 
Schritt 186 zwecks Prlifung des nachsten Requests zuruckge- 
kehrt wird. Wenn R auch nicht ein alternatives Warten be- 
trifft, wird gemaB Block 104 die Behandlung transaktionaler 
Requests durchgefuhrt (s. nachfolgende ErlMuterung zu 
Fig. 23), wonach wiederum zum Schritt 186 zuruckgekehrt wird. 
1st R bei der Abfrage 187 als leer festgestellt worden 
(Ausgang "J"), so wird bei 190 abgefragt, ob das Objekt eine 
ProzeBidentif ikationsnummer ist, und wenn nein, wird zum 
Ausgang der Prozedur 121 libergegangen; wenn das Abfrage- 
ergebnis jedoch ja ist, wird gemaB Block 190 1 getestet, ob 
der mit PID bezeichnete ProzeB am Terminieren ist; falls ja, 
wird der ProzeBmanager aufgerufen, urn ein "Schwaches ProzeB- 
Ende" durchzufiihren, s. Block 191, welcher nachstehend 
anhand der Fig. 28 noch naher beschrieben werden wird. Ist 
das Ergebnis des Tests in Block 190' negativ, so wird zum 
Ausgang der Prozedur 121 libergegangen. 

- Behandlung transaktionaler Requests : (Fig. 23, Block 104) 

Hier erfolgt einleitend bei 192 eine Deref erenzierung des 
Objekts zu O, und bei 193 wird das Verhaltnis 0 <> Objekt 
abgefragt, d.h. untersucht, ob O ungleich dem Objekt ist. 
Bei einem positiven Abf rageergebnis werden im Schritt 194 
die Transaktionalen Requests vom gegenstandlichen Objekt an 
O verschoben, und es wird gemaB Block 104 1 neuerlich die 
Prozedur 104 zur Behandlung von Transaktionalen Requests - 
hier von O - aufgerufen, wonach zum Ende der Prozedur 
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ubergegangen ward. 

1st das Abf rageergebnis bei 193 hingegen negativ, so wird im 
Schritt 195 R als der nachste abhangige ProzeB-Request von O 
definiert, und bei 196 wird abgefragt, ob R leer ist. Wenn 
nein, wird bei 197 abgefragt, ob der ProzeS terminiert hat:, 
und wenn nein, wird der Strategiemanager hinsich-tlich der 
Prozedur "Objekt soli gelesen werden", und zwar entsprechend 
der jeweiligen ProzeBidentif ikationsnummer PID, aufgerufen 
(Block 58). Hat jedoch der Prozefl bereits terminiert (s. 
Abfrage 197), so wird im Schritt 198 der Request vom Objekt 
entfernt, und im Schritt 199 wird abgefragt, ob der Zustand 
des Requests "bereit" oder " zuruckgenommen" ( " PREPARED" oder 
"CANCELLED" ) ist . Wenn nein, wird im Schritt 200 das 
Transaktions-Kommit abgebrochen, es werden die Requests an 
den Objekten entfernt, und der Ausf uhrungszustand wird als 
"FAILED" (fehlgeschlagen) definiert, wonach bei 201 eine 
Fehlermeldung abgegeben und zum Ausgang der Prozedur 
ubergegangen wird. Wenn hingegen das Abf rageergebnis bei 199 
positiv war, wird die Prozedur 98 "Transaktions-Kommit- 
Beenden" (und zwar hinsichtlich der Transaktion des gerade 
behandelten unabhangigen ProzeB-Requests ) aufgerufen, wonach 
zum Schritt 195 zurlickgekehrt wird, urn den nachsten 
abhangigen ProzeB-Request zu behandeln. 

Wenn sich bei der Abfrage 196 ergibt, daS R leer ist, d.h. 
daB keine Anfragen hinsichtlich abhangiger Prozesse mehr 
vorliegen, dann wird im Schritt 202 T als die alteste 
Transaktion aller Requests von 0 definiert, und es wird bei 
203 abgefragt, ob der Zustand von 0 gesperrt ("LOCKED") ist 
und die sperrende Transaktion jiinger als T ist oder aber 
nicht im Zustand "COMMITTING" vorliegt. Wenn nein, wird T im 
Schritt 204 nun als die sperrende Transaktion definiert, und 
es wird bei 205 der Strategiemanager aufgerufen, um die 
nachstehend anhand der Fig. 36 zu erlauternde Prozedur "ist 
Objekt exklusiv gesperrt" durchzuf iihren . Wenn eine derartige 
exklusive Sperre noch nicht vorliegt, wird weiter der 
Strategiemanager aufgerufen (Schritt 206, s. auch Fig. 35 und 
die nachfolgende Erlauterung ) , um eine "exklusive Objekt- 
Sperre" zu besorgen . Danach wird zum Ausgang der Prozedur 
104 ubergegangen. 
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Die Strategiemanager-Aufrufe 205, 206 folgen auch, wenn sich 
bei der Abfrage 203 ,ein positives Ergebnis ergibt, wobei 
dann zuvor gemaS Schritt 207 die Objektsperren aller 
Requests der sperrenden Transaktion zugunsten von T ( also 
der altesten Transaktion aller Requests von O) freigegeben 
werden, die Requests wieder an die Objekte gehangt werden, 
wonach gemaB 104" die Prozedur 104 betreffend Behandlung 
Transaktionaler Requests, und zwar nun hinsichtlich aller 
Requests der ehemals sperrenden Transaktionen, aufgerufen 
wird. Danach wird wie erwahnt bei 205 und eventuell auch 206 
der Strategiemanager zur Erzielung einer exklusiven 
Ob j ektsperre aufgerufen . 

1st bei der Prozedur 205 festgestellt worden, daB das Objekt 
bereits exklusiv gesperrt ist, so wird im Schritt 208 R als 
der nachste Transaktionale Objekt-Schreib-Request Oder 
Transaktionale Objekt-Lese-Request von T an O definiert, und 
es wird der Request R von 0 entfernt. Danach wird bei 209 
abgefragt, ob R leer ist, und wenn ja, wird zum Ausgang der 
Prozedur libergegangen; wenn R noch nicht leer ist, wird bei 
210 abgefragt, ob R das Beschreiben eines Objekts betrifft, 
und wenn ja, wird bei 211 sodann abgefragt, ob das zu 
schreibende Objekt ein nur einmal beschreibbares Objekt ist; 
wenn nein, d.h. wenn das Objekt ein aktualisierbares Objekt 
ist, wird sodann im Schritt 212 der Zustand des Objekts auf 
"gesperrt" ("LOCKED") gesetzt, der gewunschte Wert wird 
vorubergehend in das Objekt geschrieben, und es wird die 
Zeitmarke erhoht; der Request ist damit erfiillt, und es wird 
zum Schritt 208 zuruckgekehrt , um den nachsten Request zu 
behandeln. 

Ist hingegen bei der Abfrage 211 das Ergebnis, daB das zu 
schreibende Objekt ein write-once-Objekt ist, so wird bei 
213 abgefragt, ob der Zustand des Objekts "definiert" 
( "defined" ) ist, und wenn ja, kommt es zum Abbruch des 
Transaktions-Kommits gem£B Schritt 200 und zur Fehlermeldung 
gemaB Schritt 201. Wenn jedoch der Zustand des Objekts nicht 
"definiert" ist, d.h. das Abf rageergebnis bei 213 negativ 
ist, dann wird im Schritt 214 abgefragt, ob der Objektstatus 
"gesperrt" ("LOCKED") ist, d.h. ob das betroffene Objekt von 
einem anderen Schreib-Request her gesperrt ist. Wenn ja, 
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erfolgt ebenfalls ein Abbruch des Transaktions-Kommits gemSB 
Schritt 200 sowie eine Fehlermeldung gemaB Schritt 201; wenn 
nein, erfolgt; der bereits beschriebene Vorgang gem£B 212, 
bevor zum Schritt 208 zuruckgekehrt wird. 

Wenn sich bei der Abfrage 210, ob R ein Objekt-Beschreiben- 
Request ist, ein negatives Ergebnis ergibt, wird die 
Prozedur "Transaktionales Objekt-Lesen" gem&B Block 156 
aufgerufen (s. Fig .19 und zugehorige Beschreibung), wonach 
bei 215 abgefragt wird, ob die Lese-Anfrage beantwortet 
werden konnte. Wenn nein, wird zum Schritt 208 zuriickge- 
kehrt, und wenn ja, wird der Zustand des Objekts auf 
"gesperrt" ("LOCKED") gestellt, der Request ist erfvillt, s. 
Block 216, und es wird ebenfalls zum Schritt 208 
zuruckgekehrt . 

In Fig. 24 ist der Proze6-Bef ehl-Ablauf (s. Block 43 in 
Fig. 4) naher veranschaulicht . Dabei wird als erstes bei 217 
abgefragt, ob der Request einen unabhangigen ProzeB 
( indep_process ) betrifft, und wenn ja, wird der bereits vorste- 
hend im Zusammenhang mit Fig. 13 angesprochene ProzeBmanager 
betreffend Start eines unabhangigen Prozesses, Block 127, 
aufgerufen. Betrifft der Request jedoch keinen unabhangigen 
ProzeB, so wird bei 218 abgefragt,* ob der Request das Senden von 
Signalen betrifft, und wenn ja, wird bei 219 der ProzeBmanager 
betreffend Prozedur "Signal-Schicken" (s. nachfolgen'd zu erl&u- 
ternde Fig. 27) aufgerufen. Ansonsten wird bei 220 abgefragt, ob 
der Request ein "Schwaches-ProzeB-Ende" ( "coke_try_exit" ) 
betrifft, d.h. das Beenden eines Prozesses mit Erlaubnis- 
Uberpriifung; wenn ja, wird bei 191 der ProzeBmanager betreffend 
Durchfuhrung dieses Prozesses "Schwaches ProzeB-Ende" aufge- 
rufen; wenn nein, wird bei 221 abschlieBend abgefragt, ob ein 
unbedingtes Beenden eines Prozesses ( l, coke_exit" ) vom Request 
betroffen ist, und wenn ja, wird der ProzeBmanager zur Durch- 
fuhrung der Prozedur "ProzeB-Ende" aufgerufen. Die Prozeduren 
"Schwaches ProzeB-Ende" und "ProzeB-Ende" werden nachfolgend 
anhand der Fig. 28 und 29 naher beschrieben werden. 

Die vorstehend angesprochenen Prozesse sowie welters die 
bereits friiher erwahnten Prozesse "ProzeB-Kreieren" und "ProzeB- 
Aufspannen" werden nunmehr anhand der Fig. 26 bis 31 erl&utert. 
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Starten eines unabhangigen Prozesses INDEP-Prozefl-Start : 

indep_process(PID / LSYS, Site, Entry) (s. Fig. 26) 
Mit diesem Befehl wird ein unabhangiger (- autonomer) Prozefl 
gestartet, der eindeutig durch eine PID-Nuramer ( ProzeB- 
identif ikationsnummer ) bezeichnet wird. Diese PID-Nummer ist 
selbst ein Kommunikat ionsob j ekt r dessen Wert den Ausfxih- 
rungszustand des Prozesses reflektiert. Der Prozefl wird auf 
dem Rechner an der Stelle "Site" (X, Y Oder Z in Fig. 2) auf 
dem lokalen Sof twaresystem LSYS (18, 19 bzw. 20) gestartet, 
wobei zuvor - s. Schritt 223 in Fig. 26 - uberpriift wird, ob 
der aktuelle Prozefl ein Zugrif f srecht auf alle in "Entry" 
vorkommenden Objekte sowie auf die PID besitzt ( sowie auch, 
ob diese Objekte und die PID hinsichtlich der verwendeten 
Strategie kompatibel sind, ob "Site" eine gultige 
Rechneradresse ist, und ob TID eine laufende (STARTED oder 
FAILED) Transaktion bezeichnet); falls dies nicht erfiillt 
ist, wird gemafl Schritt 224 eine Fehlermeldung erzeugt. 
Falls die PID bereits als solche in Verwendung ist, ergeht 
ebenfalls eine Fehlermeldung. 

"Entry" spezifiziert die auszuf uhrende Funktion, der als 
Argumente Kommunikationsob j ekte mitgegeben werden kGnnen, 
die dieser neue Prozefl dann auch sehen darf. 

Es wird gemafl Block 176 (s. auch nachstehend zu Fig. 30) eine 
neue Prozeflstruktur generiert, falls der Prozefl auf dem 
lokalen Rechner (= "Site") laufen soli, und der Prozefl wird 
lokal angestartet; ansonst wird der Strategiemanager von PID 
aufgerufen, um dem Prozefl an den mit "Site" spezif izierten 
Rechner zu schicken. Die Zuverlassigkeit des Anstartens 
hangt von der jeweiligen Verteilungsstrategie ab. 
Es wird ferner eine Hilf stransaktion generiert, die als die 
Transaktion dieses Prozesses in seiner Prozeflstruktur 
vermerkt wird. 

Wenn ein unabhangiger Prozefl von einer zuverlassigen 
( Protokollf lag "RELIABLE") Verteilungsstrategie ist, wird er 
nach einem Systemfehler wiederhergestellt , und falls er noch 
nicht terminiert hat, wird er dann auch automatisch wieder 
angestartet . 

Unabhangige Prozesse werden vom Koordinations-Server solange 
gestartet, bis sie einen endgiiltigen Ausf iihrungszustand 
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erreicht haben. 

Schicken von Signalen: signal (PID, Signal) (s. Fig. 27) 
Mit diesem Request: wird ein spezif iziertes Signal (z.B. 
"ABORT", "COMMIT" oder 11 CANCEL" etc.), zu dem noch optional 
Flags spezifiziert werden konnen, die z.B. besagen, ob das 
Signal an Unterprozesse weitergereicht werden soil, an den 
ProzeS gesendet, der durch die PID-Nummer bezeichnet wird. 
Hierbei wird in den aufgerufenen Prozeduren zweckmSBig auch 
iiberprtift, ob PID ein Kommunikat ionsob j ekt ist, das einen 
ProzeB bezeichnet, und ob es sich urn ein gultiges Signal 
handelt (z.B. darf ein Benutzer an einen abhangigen ProzeB 
( n dep_process" ) , der bereits "fertig" ("PREPARED") ist, 
nicht mehr ein Signal "Abbruch" ("ABORT") schicken). 
Falls der durch die PID-Nummer bezeichnete ProzeB auf einem 
fremden Rechner lauft (s. Abfrage 225 in Fig.27), wird der 
Strategiemanager von PID aktiviert, urn das Signal an den 
Agenten auf dem fremden Rechner weiterzuleiten (Block 226; 
Prozedur "Signal-Schicken" ; s. nachfolgend zu Fig. 38), der 
es dort an den entsprechenden ProzeB schicken wird. Die 
Zuverlassigkeit des Weiterleitens hangt von der 
Verteilungsstrategie ab ( "RELIABLE" oder "UNRELIABLE") . 
Im iibrigen werden gemaB Fig.27 bei 227, 228, 229 bzw. 230 
die jeweiligen Signale auf ihren Gegenstand ("ABORT", 
"COMMIT" , "CANCEL" etc.) abgefragt, und zutref f endenf alls 
wird das zugehorige "ProzeB-Ende" mit dem entsprechenden 
Exit-Wert ("ABORT" bzw. "COMMIT" bzw. "CANCEL"), Block 191, 
aufgerufen, das nachfolgend unter Bezugnahme auf Fig. 28 
erlautert wird . 

Beenden eines Prozesses mit Erlaubnis-Uberpriif ung ( Schwaches 

ProzeB-Ende): coke_try_exit (ExitValue) (s. Fig. 28) 
Dieser Befehl dient zum Beenden eines aktuellen Prozesses, 
wobei der "Exit-Wert" ("ExitValue") analoge Werte wie 
Signal-Typen annehmen kann. Der erreichte Ausf uhrungszustand 
wird in die PID geschrieben . Ist der gewunschte Zustand 
nicht erreichbar, so retourniert "coke_try_exit " eine 
Fehlermeldung . 

Es wird also - nach einem "Atomaren Schritt START" 231 - 



einleitend uberpruft, ob der " Exit:- Wert:" erlaubt ist 

(Abfrage 232) - das hangt davon ab, ob "coke_try_exit" vom 

Benutzer oder vom System aufgerufen wurde. Letzteres ist 

z.B. der Fall, wenn intern ein Signal "ABORT" oder ein 

Signal "COMMIT " an einen ProzeS geschickt wird. 

Erlaubt ist: " Exit- Wert " - von wem - in ProzeS welchen Typs 

(bei dem der Ausf uhrungszustand entweder noch nicht gesetzt 

ist oder den explizit angegebenen Wert hat): 

z.B. "PREPARE" von Benutzer in einem unabhSngigen oder 

abhangigen ProzeB; 

oder : 

"COMMIT" von Benutzer an INDEP-ProzeB .( nicht gesetzt oder 
SUCCEEDED) oder von SYSTEM an DEP-ProzeB (PREPARED); 
oder: 

"ABORT" von Benutzer an INDEP-ProzeB (nicht gesetzt oder 
SUCCEEDED) oder an DEP-ProzeB oder yon SYSTEM an DEP-ProzeB 
(nicht gesetzt oder PREPARED); 
oder: 

"CANCEL" von Benutzer an DEP-ProzeB (nicht gesetzt oder 
PREPARED ) . 

Danach wird am ProzeB vermerkt, daS er am Terminieren ist 
(Block 233). 

Wenn der Exit-Wert "ABORT" ist (s. Abfrage 234 in Fig. 28), 
wird nach Beschreiben der PID (Block 235) die atomare 
"coke_try_exit "-Prozedur wie folgt beendet ( im folgenden 
Prozedur A genannt ) : alle schlafenden Anfragen an PID sowie 
ein m5gliches ProzeBende eines Vaterprozesses werden aufge- 
weckt (Block 121): nicht mehr benotigte Transaktionsstruk- 
turen von f ehlgeschlagenen Top-Level-Transaktionen dieses 
Prozesses werden nach Uberpriifen, ob ein endgliltiger 
ProzeBzustand vorliegt (Schritt 236), entfernt (Block 237); 
die Ref erenzzahler aller Objekte, auf die der terminierende 
ProzeB zugreifen durfte, werden zwecks Garbage-Collection, 
Block 238 (s. auch Fig. 40) ( abhangig vom Protokoll der PID 
des Prozesses), dekrementiert ; die ProzeBstruktur wird 
entfernt (Schritt 239), wonach der Atomare-Schritt ENDE 
( Recoverymanager ) folgt (Block 240). 

Wenn es sich urn einen unabhangigen ProzeB ( " indep_process" ) 
handelt (s. Abfrage 241, Ausgang J), wird nach einer Zu- 



- 46 - 



standsabf rage bei 242, wenn der Zustand der Hilfstransaktion 
"gestartet" ( "STARTED" ) ist, das schwache Transaktions- 
Kommit " trans_try_commi t " von seiner Hilfstransaktion 
aufgerufen (Block 73). 

Falls der Zustand der Hilfstransaktion " COMMITTED" ist 
(Abfrage 243), wird (falls der Exit-Wert "PREPARE" ist) der 
Ausf uhrungszustand des Prozesses im Block 235 auf 
" SUCCEEDED " gesetzt ( hier kann gegebenenf alls auch 
"PREPARED" verwendet werden), und falls der Exit-Wert 
"COMMIT" ist, wird der Ausf uhrungszustand des Prozesses auf 
" COMMITTED " gesetzt, und die vorstehend erlauterte Prozedur 
A wird angewendet . Falls bei der Abfrage 243 der Zustand 
nicht "COMMITTED" ist, erfolgt eine Fehlermeldung (Schritt 
244 ) . 

Wenn es sich urn einen abhangigen ProzeS ( "dep_process" ) 
handelt (negatives Ergebnis bei der Abfrage 241), wird: 
falls der "Exit-Wert" "PREPARE" ist (Abfrage 245), der 
Ausf uhrungszustand seiner Hilfstransaktion berechnet (dieser 
ist noch nicht bestimmbar, wenn eine Untertransaktion Oder 
ein abhangiger Prozefi der Hilfstransaktion noch nicht termi- 
niert hat; dies geht in Ordnung, wenn alle Untertransakti- 
onen und jeder abhangige ProzeS gutgegangen sind, sonst 
nicht); mit dem schwachen Transaktions-Kommit wird gewartet 
(s. Abfrage 246), bis sich der Zustand bestimmen laSt; ist 
dieser nicht in Ordnung, wird eine Fehlermeldung retour- 
niert; ansonst werden alle transaktionalen Anfragen der 
Hilfstransaktion des Prozesses an die Transaktion des abhan- 
gigen Prozesses transferiert (Block 248); ist diese Trans- 
aktion nicht lokal (s. Abfrage 247), so muB der Transfer vom 
Strategiemanager ( entsprechend der PID des Prozesses) 
durchgefuhrt werden (s. Block 249; vgl. auch Fig.39); erst 
danach wird der Ausgangszustand des Prozesses auf "PREPARED" 
gesetzt (Block 235), und es folgt die Prozedur A. 
Haben alle Unterprozesse der Hilfstransaktion terminiert (s. 
Abfrage 250), nachdem ein Kommit der Hilfstransaktion als 
nicht moglich festgestellt wurde (Abfrage 246), so erfolgt 
eine Fehlermeldung (Schritt 251); ansonsten folgt die 
Prozedur A. 

falls der "Exit-Wert" nicht "PREPARE" ist (s. Abfrage 245), 



muS er "ABORT" sein, d.h. der Ausgangszustand des Prozesses 
wird auf "ABORTED" (Block 235) gesetzt und die Prozedur A 
angewendet . 

Beenden eines Prozesses: coke_exit (ExitValue) (s. Fig. 29) 
Der Ablauf ist hier wie beim "Schwachen ProzeS-Ende" (s. 
oben bzw. Block 191 in Fig. 28), nur daB im Fehlerfall der 
ProzeS (s. Abfrage 252) automatisch abgebrochen wird, d.h. 
es wird automatisch das Signal "ABORT" an den aktuellen 
ProzeS geschickt (Block 219 "Signal-Schicken" , "Abort" an 
ProzeS ) . 

ProzeS-Kreieren : create_process (s. Fig. 30) 

Nach einem einleitenden Aufruf des Recoverymanagers 
betreffend "Atomarer Schritt START" bei 253 wird gemaS 
Schritt 254 getestet, ob fur den ProzeS mit der angegebenen 
Nummer bereits eine ProzeS-Struktur existiert; wenn ja, wird 
sofort zum ProzeS-Ende ubergegangen; wenn nicht, wird der 
Strategiemanager aufgerufen, urn f estzustellen, ob das Objekt 
exklusiv gesperrt ist, s. Block 205 sowie die nachfolgend zu 
erlauternde Fig. 36. Falls nein, wird der Strategiemanager 
aufgerufen, urn gemaS Block 206 (s. auch Fig. 35) eine exklu- 
sive Objekt-Sperre fur den betreffenden ProzeS zu besorgen, 
und es wird zum Schritt 205 in Fig. 30 zuriickgekehrt , wobei 
dann, da nun das Objekt exklusiv gesperrt ist, in der 
Prozedur weitergegangen und bei 255 abgefragt werden kann, 
ob die .angegebene ProzeSidentif ikationsnummer PID bereits 
zur Identif izierung eines Prozesses in Verwendung ist. 
Sollte dies zutreffen, so wird bei 256 eine Fehlermeldung 
abgegeben, und das Ende des Prozesses ist erreicht. Wenn die 
PID-Nummer noch nicht verwendet wird, wird nun im Schritt 
257 am PID-Objekt vermerkt, daS es eine PID darstellt, d.h. 
es dient ab nun zur Identif izierung dieses Prozesses. Danach 
wird abhangig davon, ob der ProzeS am lokalen Rechner durch- 
gefuhrt werden soil (Abfrage 258), dann, wenn der lokale 
Rechner zustandig ist, die gewlinschte neue ProzeS-Struktur 
angelegt, Block 259, und der Transaktionsmanager wird zum 
Start einer Top- Level -Transakt ion gem£S Block 69 (s. auch 
Fig. 10) aufgerufen, wonach die neue Transaktion im Schritt 
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260 als Hilfstransaktion des betrof f enen Prozesses einge- 
tragen wird; danach wird "ProzeB-Aufspannen" 29 (s. auch 
Fig. 31) aufgerufen; abschli^Bend wird der Recoverymanager 
zur Durchfuhrung des "Atomai^en Schritts-ENDE" aufgerufen, s. 
Block 261 in Fig. 30. Wenn slch bei der Abfrage 258 ergibt, 
daB der ProzeB nicht am lokaken Rechner durchzufiihren ist, 
wird der Strategiemanager zujr Durchfuhrung der Prozedur 
"ProzeB-Schicken" gemaB Bloek 262 aufgerufen, wonach eben- 
falls der End^Sc^ritt 26^/f olgt . Die Prozedur 262 "ProzeB- 
Schicken" wird nachfolg&nd anhand der Fig. 37 nSher 
erlautert . 

- ProzeB-Aufspannen : (s. Fig. 31) 

Beim ProzeB-Aufspannen wird abhangig davon, ob das lokale 
Softwaresystem als vorubergehend Oder als permanent auftritt 
(Abfragen 263 - "Softwaresystem ist X-transient ?" , 264 - 
"Softwaresystem ist transient ?" und 265 - "Softwaresystem 
ist permanent ?") sowie abhangig davon, ob der lokale Server 
lauft (Abfragen 266, 267) entweder der lokale Server im 
Schritt 268 angestartet, urn gemaB Schritt 269 die Entry- 
Angaben an den Server zu schicken und den ProzeB zu starten, 
oder aber der letztere Vorgang 269 wird - im Fall eines 
permanenten lokalen Sof twaresystems , wenn der Server bereits 
lauft, unmittelbar durchgef uhrt . Im Fall eines X- transienten 
lokalen Sof twaresystems (Abfrage 263 ) wird im Falle, daB 
der Server bereits lauft (s. Abfrage 266), die Triggerung 
der gewunschten Arbeit bewirkt, wenn der Server frei ist, 
und zu diesem Zweck wird in einer Schleife erneut der 
Vorgang "ProzeB-Aufspannen" gemaB Block 29 1 aufgerufen. Im 
Falle daB das lokale Softwaresystem weder X-transient noch 
transient noch permanent ist, wird gemaB Schritt 270 eine 
Fehlermeldung abgegeben . 

AbschlieBend soil noch anhand der Fig. 32 bis 40 der 
Strategiemanager erlautert werden, der fur die Festlegung der 
Verteilungsstrategie, auch Kommunikationsprotokoll genannt, 
verantwortlich ist . 
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Befehl ausfiihren: (s. Fig. 32) 

Bei der Ausfiihrung des Befehls konnen Nachrichten an andere 
Koordinations-Server geschiipkt werden, was von der 
jeweiligen Verteilungsstrategie kontrolliert wird. Im Ablauf 
gemSS Fig. 32 wird nach dem Utomaren Schritt START" des 
Recoverymanagers bei 271 der) Strategiemanager der 
betroffeneri Strategie zur Ausfuhrung des Befehl aufgerufen 
(Block 272), und es wird sodrann im Schritt: 273 O als das 
nfichste Objekt^ def in^rt^j/uas in der Bearbeitung vorkam, und 
im Schritt: 274 abgefragt, ob 0 leer ist. Solange O nicht 
leer ist, wird fur den Fall, daB eine exklusive Sperre fur 
das Objekt gesetzt bzw. ein neuer Objekt- Wert erhalteh 
worden ist (Abfrage 275), der Transaktionsmanager zwecks 
Aufwecken des Objekts, Block 121 (s. auch Fig. 22), aufge- 
rufen. Je nach Verteilungsstrategie (SM) kann nach Block 274 
noch "abgefragt werden, ob es eine Verlustnachricht fur das 
Objekt gab (wegen eines fatalen Fehlers ) und dann 
Transaktions-Abort im Transaktionsmanager aufgerufen werden 
(ist in Fig. 32 zwecks Vereinf achung nicht dargestellt ) . Wenn 
gemaS Abfrage 274 kein Objekt mehr vorhanden ist, wird vom 
Recoverymanager der "Atomare Schritt ENDE " bei Block 276 
durchgef iihrt . 

Behandle Nachricht von anderem Koordinations-Server: 
(CoKe) (s. Fig. 33) 
Hier wird einleitend im Schritt 277 die Strategie der 
erhaltenen Nachricht f estgehalten, und es wird sodann gem&B 
Block 278 die Prozedur " Bef ehl-Ausf uhren" ( gemafi Fig. 32) 
hinsichtlich der Behandlung der Nachricht, die von einem 
CoKe kommt, aufgerufen. 

Objekt soil gelesen werden: (s. Fig. 34) 

Hier wird einleitend die Strategie des zu lesenden Objekts 
im Schritt 279 f estgehalten, und dann wird wiederum im Block 
278 die Prozedur "Bef ehl-Ausf iihren" , hier hinsichtlich 
"Objekt soil gelesen werden", aufgerufen. 



Exklusive Objekt-Sperre besorgen: (s. Fig. 35) 

Nachdem hier einleitend die Strategie des Objekts, ftir das 
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die exklusive Sperre besorgt werden soil, f estgehalten wurde 
(Schritt 280), wird im Block 278 die Prozedur "Befehl- 
Ausfuhren" : Exklusive Ob j ekt-Sperre besorgen aufgerufen. 

- 1st: Objekt exklusiv gesperrt: (s. Fig. 36) 

Nach Festhalten der Strategie des Objekts, fur das getestet 
werden soli, ob eine exklusive Sperre vorhanden ist, gemSS 
Schritt 281, folgt wieder die Prozedur "Bef ehl-Ausf iihren" 
(Block 278), nun hinsichtlich der Abfrage, ob das Objekt 
exklusiv gesperrt ist. 

- Prozefi-Schicken : (s. Fig. 37) 

Einleitend wird hier im Schritt 282 die Strategie des P1D- 
Objekts des zu schickenden Prozesses f estgehalten, wonach im 
Schritt "Befehl-Ausf iihren" 278 der Prozefl geschickt wird. 

- Signal-Schicken : (s. Fig. 38) 

Hier wird die Strategie des PID-Objekts des Prozesses 

f estgehalten, an den das Signal zu schicken ist (Schritt 

283), bevor gemaB Block 278 das Signal geschickt wird. 

- Transf erieren transaktionaler Requests : (s. Fig. 39) 

Bevor gemaB Schritt 278 der Befehl ausgefuhrt und trans- 
aktionale Requests transf eriert werden, wird die Strategie 
der PID der Hilf stransaktion f estgehalten, deren Requests 
transf eriert werden sollen, s. Schritt 284 in Fig. 39. 

- Auf raumen : (Garbage Collection) (s. Fig. 40, Prozedur 238 in 

Fig. 28) 

Hier wird die Strategie des auf zuraumenden Objekts 

f estgehalten (Schritt 285), bevor die Auf raumarbeit (Garbage 

Collection) unter Ausfuhrung des Befehls, Block 278, 

erfolgt. 

Was die verwendbaren Strategien betrifft, so wird bevorzugt 
eine Basis-Strategie festgelegt und in der Regel verwendet. 
Basis-Strategien konnen z.B. PR_DEEP und AR_FLAT sein; dabei 
bedeutet PR_DEEP ( "passive replication with deep object tree" ) 
eine passive Replikation bei einem in die Tiefe gehenden 
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Objektbaum; AR__FLAT ("active replication with flat object tree") 
bedeutet eine aktive Replikation bei einem flachen Objektraum 
und bietet noch mehr ZuverlSssigkeit und Verf ugbarkeit als 
PR_DEEP. Als Strategie-Flags ( Protokollf lags ) kGnnen unter 
anderem die Flags RELIABLE/UNRELIABLE; MOB I LE / NON_MOB I LE ; 
GARBAGE_COLLECTION/NO_GARBAGE_COLLECTION; SECURITY/NO_SECURITY; 
TOPO LOG Y_GRAPH / NO_TOPOLOGY_GR APH eingesetzt werden. Hierbei 
bedeuten : 

RELIABLE/UNRELIABLE: ob kritische ZustandsSnderungen im Daten- 
und Logfile gespeichert werden sollen, urn Recovery zu 
erm6gl i chen ; 

MOBlLE/NON_MOBILE : ob ein Rechner im laufenden Betrieb 
intentional vom Netzwerk abgesteckt werden kann; 

GARBAGE_COLLECTION/NO_GARBAGE_COLLECTION: ob das Objekt 

automatisch aufgeraumt werden soli, veflh es nicht mehr 
benotigt wird ; 

SECURITY/NO_SECURITY: ob iiberpriift werden soli, ob ein ProzeB 
autorisiert ist, auf ein Objekt zuzugreifen; 

TOPOLOGY_GRAPH/NO_TOPOLOGY_GRAPH: ob ein Topologie-Graph als 
Hilf ststruktur verwaltet werden soil, der Information 
speichert, auf welchen Rechner sich Kopien des Objektes 
befinden, und damit das Replikationsverhalten fur sehr groSe 
Ob j ekte optimiert . 

Die Anwendung des vorliegenden Systems soil nun nachfolgend 
zusammen mit dabei erzielbaren Vorteilen anhand von zwei 
Anwendungsbeispielen noch naher erlautert werden. 

Beispiel 1: Produzent-Konsument 

Ein klassisches Beispiel fur die Verwaltung gemeinsamer 
Ressourcen ist das "Produzent-Konsument" Problem, bei dem eine 
beliebige Anzahl von verteilten, parallel laufenden Prozessen 
existiert, die entweder Daten produzieren Oder Daten verarbeiten 
(= konsumieren ) . Alle produzierten Daten sollen gleichberechtigt 
von jedem Konsumenten bezogen werden konnen (d.h. ohne 
Bevorzugung ) , und sobald ein Datum konsumiert wurde, darf es 
kein weiteres Mai konsumiert werden. 

Eine auf "write-once" -Kommunikationsobjekten basierende 
L5sung mit Hilfe des beschriebenen Koordinations-Systems sieht 
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als gemeinsame Datenorganisationsstruktur eine unendlich gro6 
werdende Liste vor, in die der Reihe nach die produzierten Daten 
geschrieben werden (eine solche Liste wird "Stream" genannt ) 
Der Anfang der Liste wird durch ein Kommunikationsobjekt , 
"Wurzel " genannt, dargestellt, in das der erste Produzent in 
einer Transaktion eine Listenzelle schreibt, die aus zwei 
Elementen besteht, n&mlich einem Kopf und einem Rumpf . In den 
Kopf schreibt der Produzent in derselben Transaktion sein Datum 
sowie ein neu angelegtes Kommunikationsobjekt , genannt "Flag", 
dessen Bedeutung weiter unten erklart wird. In den Rumpf 
schreibt der Produzent in derselben Transaktion ein weiteres neu 
angelegtes Kommunikationsob j ekt , genannt " ListenRumpf . 

" ListenRumpf " stellt den Rest der Liste dar, d.h. in diesen 
"ListenRumpf" wird der nachste Produzent wiederum in einer 
Transaktion eine Listenzelle hineinschreiben, die sein Datum, 
sowie ein neues Flag und einen neuen "ListenRumpf" enthalt 
u.s.w., vgl . auch die nachfolgende Tabelle 1: 

Tabelle 1: 

Datenorganisation als Stream 



Listenzelle 



< 



> 



Liste 



= [(Datumi, Flagl ) 



ListenRumpf 1 ] 



< 



> 



< 



> 



Kopf der Liste 



Rumpf der Liste 



ListenRumpf 1 
ListenRumpf 2 



[(Datum2, Flag2) 
[(Datum3, Flag3 ) 



ListenRumpf 2 ] 
ListenRumpf 3 ] 



u . s . w . 



d.h. 



Liste 



[(Datumi, Flagl), (Datum2, Flag2 ) , (Datum3, Flag3 ) 
ListenRumpf N] 



Die Synchronisation bei gleichzei tigem Schreibzugrif f meh- 
rerer Produzenten PR1 , . . . , PRk auf denselben ListenRumpf funk- 
tioniert f olgendermaBen : da jeder Produzent PRi (i = 1, k) 
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in einer Transaktion Tl, . Tk auf das Kommunikationsobjekt, 
das den ListenRumpf darstellt, zu schreiben versucht, kann nur 
eine dieser Transaktionen gutgehen ( "kommitten" ) . Wenn 
angenommen die j-te Transaktion Tj erfolgreich war, d.h. der 
Produzent PRj sein Datum erfolgreich in den Stream geschrieben 
hat, dann miissen alle anderen Produzenten PRi (i = 1, k und 

i <> j ) die Schreibanf orderung auf den ListenRumpf in ihrer 
jeweiligen Transaktion Tj zurucknehmen ( "cancel " -Befehl ) , den 
neuen Inhalt des ListenRumpf es auslesen, diesem den neuen 
ListenRumpf entnehmen und nun versuchen, die gewiinschte Listen- 
zelle mit dem produzierten Datum in den neuen ListenRumpf zu 
schreiben (als neu angemeldete Schreiboperation in der Trans- 
aktion Tj ) . Unter der Annahme, daS nicht immer zwei Produzenten 
existieren, die gleichzeitig auf denselben ListenRumpf zu 
schreiben versuchen, ist garantiert, daS jeder Produzent seine 
Daten im gemeinsamen Stream zur Verfiigung stellen kann. 

Urn ein Datum zu konsumieren, liest der jeweilige Konsument 
Ki den Stream soweit durch, bis er einen Eintrag findet, in dem 
das "Flag" noch undefiniert ist, was bedeutet, daB noch kein 
Konsument dieses Datum verarbeitet hat . Der Konsument Ki startet 
eine Transaktion und versucht in "Flag" den Wert "verarbeitet" 
hineinzuschreiben . Geht das Kommit der Transaktion gut, so kann 
der Konsument Ki nun das Datum verarbeiten. Geht das Transak- 
tions-Kommit nicht gut, bedeutet dies, da/3 gerade ein anderer 
Konsument dieses Datum konsumiert hat, und der Konsument Ki muB 
die Schreiboperation auf "Flag" zurucknehmen, die nachste 
Listenzelle aus dem aktuellen ListenRumpf lesen und - falls dort 
das Kommunikationsobjekt "Flag" noch undefiniert ist - nun 
neuerlich versuchen, in der Transaktion "Flag" auf "verarbeitet" 
zu setzen. Damit werden gleichzeitige Konsumentenzugrif f e auf 
dasselbe Datum synchronisiert , und es ist garantiert, daB jedes 
Datum von maximal einem Konsumenten verarbeitet wird. 

Jeder Produzenten- und KonsumentenprozeB wird als 
unabhangiger ProzeB angestartet, der als Argument das Wurzel- 
Kommunikationsobjekt der Liste (Anfang der Liste) mitbekommt. 
Damit hat jeder dieser Prozesse Zugriff auf alle 
produzierten/konsumierten Daten . 

Die Fehlertoleranz kann beim Anlegen aller verwendeten 
Kommunikationsobjekte gesteuert werden: Es sei angenommen, daB 



fur diese Kommunikationsobjekte eine Verteilungsstrategie (siehe 
Tabellen 2, 3 und 4, Strategie PRX ) gewahlt wurde, fur das die 
Option "RELIABLE " gesetzt ist. Dann ist das beschriebene 
Produzenten-Konsumenten-System sowohl gegen Systemfehler als 
auch gegen Netzwerkf ehler resistent. Beim Absturz eines Rechners 
wird der lokale Koordinations-Server wieder angestartet, dieser 
stellt alle Kommunikat ionsob j ekte sowie alle Produzenten- und 
Konsumentenprozesse wieder her und startet letztere mit dem 
urspriinglichen Wurzel-Kommunikationsobjekt als Parameter wieder 
an. Damit kann jeder dieser Prozesse wieder Zugang zu alien 
produzierten Daten im Stream erlangen und seine Arbeit wieder 
aufnehmen. Ein Konsument liest nun den Stream bis zum ersten 
Datum, dessen zugeordnetes Flag noch undefiniert ist; ein 
Produzent versucht, vom Wurzel-Kommunikationsobjekt ausgehend, 
beim ersten ListenRumpf, beim zweiten ListenRumpf, u.s.w. in den 
Stream zu schreiben; dabei wird es bei jedem schon beschriebenen 
Kommunikationsob jekt zu einem Transaktions-Kommit-Fehler kommen, 
der Produzent nimmt daher die Schreiboperation zuriick, liberliest 
das beschriebene Kommunikationsobjekt und probiert beim nfichsten 
ListenRumpf weiter, bis er am Ende der Liste angelangt ist und 
dort sein Datum abstellen kann. Eine sinngemafie Optimierung kann 
noch fur diesen "Recovery" -Fall angebracht werden, in der die 
Logik des Produzenten so erweitert wird, daB er immer testet 
(mit Hilfe von blockierendem Lesen ) , ob ein ListenRumpf bereits 
definiert ist, bevor er seine Schreiboperation darauf ansetzt, 
und daB er, falls der ListenRumpf schon definiert ist, diesen 
sofort liberliest- Netzwerkf ehler werden sowohl bei "RELIABLE" - 
als auch bei "UNRELIABLE" -Strategien maskiert, wobei letztere 
aber nur solange dafur garantieren kdnnen, solange keine Sys- 
temfehler ( Rechnerausf alle ) auftreten. Dafur ist ublicherweise 
bei "UNRELIABLE "-Strategien mit einer besseren Performance zu 
rechnen; d.h. der Benutzer kann je nach Anwendungsbediirf nis die 
Fehlertoleranz- Performance am Kommunikationsobjekt einstellen : 
das die Produzenten bzw. Konsumenten darstellende Programmsystem 
bleibt immer identisch. Weitere Abstimm-Moglichkeiten bestehen 
z-B. hinsichtlich der Ver f iigbarkeit und des Replikationsver- 
haltens (d.h. auf welchem Rechner Kommunikationsobjekte 
tats&chlich Plattenplatz beanspruchen ) . 

In der nachf olgenden Tabelle 2 ist die Logik des 
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Produzenten, deni das Kommnunikationsob j ekt WURZEL ubergeben 
wurde, in prozeduraler Pseudonotation veranschaulicht, wobei nur 
hier beispielshalber (in den nachf olgenden Tabellen nicht ) auch 
die vorstehend angegebenen Namen ftir die einzelnen Funktionen 
zusStzlich angefvihrt sind. 

Tabelle 2 

PRODUZENT ( WURZEL ) 

O: - WURZEL 
SCHLEIFE_1 : 

ERZEUGE NACHSTES DATUM 

ERZEUGE ZWEI NEUE KOMMUNIKATIONSOB JEKTE FLAG UND LISTENRUMPF 
VON STRATEGIE PRX 

( "Anlegen von Kommunikationsobjekten" ) 
STARTE NEUE TOP-LEVEL-TRANSAKTION ( = T ) 

( " Top- Level-Transakt ions-Start " ) 

SCHLEIFE_2: 

WENN DAS NICHT-BLOCKIERENDE LESEN ("Lesen eines Objekts" ) 
VON 0 GUTGEHT: 

DER GELESENE WERT SEI DIE LISTENZELLE [KOPf|rUMPF] 

0: = RUMPF 

GOTO SCHLEIFE_2 

SCHREIBE IN T DEN WERT [(DATUM, FLAG ) | LISTENRUMPF] IN 0 
( = OPERATION 0P1 ) ( "Objekt-Schreiben" ) 
VERSUCHE T ZU KOMMITTEN ("Schwaches Transaktions-Kommit" ) 
WENN KOMMIT VON T GUTGEHT: 

0: = LISTENRUMPF 

GOTO SCHLEIFE_1 
ANSONST 

RUCKNAHME ("cancel'* ) VON DER SCHREIBOPERATION (0P1) AUF 
0 IN T 

GOTO SCHLEIFE_2 

In Tabelle 3 1st: die Logik des Konsumenten, dem das 
Kommunikationsob j ekt WURZEL ubergeben wurde, in prozeduraler 
Pseudonotation veranschaulicht : 
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Tabelle 3 
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KONSUMENT ( WURZEL ) \ 

O: = WURZEL \ 
SCHLEIFE_3: ^ 

STARTE NEUE TOP-LEVEL-TRANSAKTION (= T) 
SCHLEIFE_4: . j 

BLOCKIERENDES LESEN VON 0: \ 

DER GELESENE WERT SEI EJlE LISTENZELLE [(DATUM, 
FLAGT^i ST^RUlipF ] 
0: = LISTENRUMPF 
WENN FLAG DEFINIERT 1ST 

GOTO SCHLEIFE_4 
ANSONST 

SCHREIBE IN T DEN WERT " VERARBEITET" IN FLAG 
(= OPERATION 0P2) 
VERSUCHE T ZU KOMMITTEN ("Schwaches Transaktions-Kommit" ) 
WENN KOMMIT VON T GUT GEHT : 

VERARBEITE DATUM 

GOTO SCHLEIFE_3 
ANSONST 

RUCKNAHME VON DER SCHREIBOPERATION ( OP2 ) AUF FLAG IN T 
GOTO SCHLEIFE_4 

Die nachfolgende Tabelle 4 zeigt das Anstarten von N 
Produzentenprozessen und M Konsumentenprozessen auf den Rechnern 
Ri.-.RN bzw. R1..,RM: 

Tabelle 4 

ERZEUGE NEUES KOMMUNIKATIONSOB JEKT WURZEL VON STRATEGIE PRX 

STARTE UNABHANGIGEN PROZESS PP1 AUF RECHNER Rl ; DIE 

AUSZUFUHRENDE FUNKTION SEI PRODUZENT ( WURZEL ) 

STARTE UNABHANGIGEN PROZESS PP2 AUF RECHNER R2 ; DIE 

AUSZUFUHRENDE FUNKTION SEI PRODUZENT ( WURZEL ) 

STARTE UNABHANGIGEN PROZESS PPN AUF RECHNER RN ; DIE 
AUSZUFUHRENDE FUNKTION SEI PRODUZENT ( WURZEL ) 
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STARTE UNABHANGIGEN PROZESS KP1 AUF RECHNER Rl ; DIE 

AUSZUFUHRENDE FUNKTION SEI KONSUMENT ( WURZEL ) 

STARTE UNABHANGIGEN PROZESS KP2 AUF RECHNER R2 ; DIE 

AUSZUFUHRENDE FUNKTION SEI KONSUMENT ( WURZEL) 

STARTE UNABHANGIGEN PROZESS KPM AUF RECHNER RM; DIE 
AUSZUFUHRENDE FUNKTION SEI KONSUMENT ( WURZEL ) 

Dieses Beispiel demonstriert auch die MSglichkeit, unendlich 
lang laufende Prozesse zu spezif izieren: sowohl die Produzenten- 
als auch die Konsumentenprozesse laufen unendlich und iiberleben 
sowohl System- als auch Netzwerkf ehler , sofern eine "RELIABLE" - 
Verteilungsstrategie gewahlt wurde. 

Das Hinzunehmen neuer Produzenten und Konsumenten ( auf ver- 
teilten Rechnern ) erfolgt dynamisch ("dynamic scale-up") durch 
Anstarten eines Prozesses auf dem entsprechenden Rechner, dem 
das Wurzel-Kommunikationsobjekt als Parameter ubergeben wird. 

Eine Autorisierung ist abhangig von der gewahlten Vertei- 
lungsstrategie gegeben, indem nur ein dezidiert als Konsument 
resp. als Produzent angestarteter ProzeB auf die Daten des 
Streams zugreifen darf . Wenn angenommen in der verteilten 
Umgebung noch weitere parallel laufende Prozesse existieren, 
dann darf keiner dieser Prozesse auf die Stream-Daten zugreifen, 
selbst wenn er zufallig die Objektidentif ikationsnummer eines im 
Stream enthaltenen Kommunikationsob jekts "errat", wobei davon 
ausgegangen wird, daB dieses Kommunikationsobjekt weder in der 
ihm iibergebenen Parameterliste aufscheint, noch als Unter- 
Kommunikat ionsob j ekt in ein fur diesen ProzeB zugSngliches 
Kommunikationsob jekt geschrieben wurde, noch -von diesem ProzeB 
angelegt wurde . 

Bekannte Werkzeuge fur verteiltes Programmieren erlaubten 
eine dermaBen einfache und kurze Spezif ikation dieses 
klassischen Problems nicht, bei der der Programmierer vdllig von 
Hardware- und Netzwerkaspekten befreit wird und trotzdem die 
Moglichkeit hat, die Performance etc. des Programms v^llig 
seinen Anwendungsbedvirf nissen anzupassen . 

Das Produzenten-Konsumenten-Problem findet sich als Grund- 
schema in einer breiten Klasse von verteilten Anwendungs- 
problemen wieder, wie zum Beispiel im verteilten Banking, wo die 
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gemeinsamen Tresorreserven verteilter Bankschalter als Stream 
verwaltet werden, oder die Verwaltung von Workflow Daten. 
Beispiel 2: Reisebuchung 

Es soil eine Reise arrangiert werden, zu der folgende 
Buchungen benotigt werden: ein Flug von Wien nach Paris, ein 
Hotelzimmer in Paris und ein Auto in Paris. Der Flug kann bei 
einer von drei Fluglinien A, B oder C gebucht werden. Das 
Hotelzimmer kann entweder im Hotel H oder im Hotel I gebucht 
werden. Das Auto kann bei einem Autoverleih V oder W gemietet 
werden. Es wird angenommen, daB der Kunde keine Buchungsprfi- 
ferenzen vorgibt. Welters gilt, daB eine Flugbuchung storniert 
werden kann. Es ist dann "STORNO der Buchung " als Kompensations- 
aktion in der entsprechenden Flugliniendatenbank aufzurufen. 
Daher braucht man nicht zu fordern, daB das lokale Datenbank- 
system der Fluglinie ein 2-Phasen-Kommit bietet, d.h. die 
Flugbuchungstransaktion kann dort ehestmoglich abgeschlossen 
werden, damit die lokale Flugliniendatenbank nicht zu lange von 
der globalen Reisebuchungstransaktion blockiert wird. 

Hotelbuchungs- und Autovermietungstransaktionen sollen nicht 
kompensierbar sein, d.h. hier muB gefordert werden, daB die 
jeweiligen Datenbanken ein 2-Phasen-Kommit vorsehen und in der 
Lage sind, die Sperren auf die betroffenen Daten bis zum Kommit 
der globalen Reisebuchungstransaktion zu halten. 

Es gibt im vorliegenden Koordinations-System mehrere M6g- 
lichkeiten, dieses Problem zu losen, die einen unterschiedlichen 
Grad an Parallelitat garantieren. Die im folgenden gezeigte 
Losung bietet eine maximale Parallelitat. 

Die gesamte Reisebuchung ist als Transaktion T dargestellt. 
Alle Flugbuchungen werden parallel als unabhangige Prozesse (die 
selbstandig kommitten) angestartet, die die Hilf sf unktion 
K_BUCHEN ausfuhren. K_BUCHEN steht fur " kompensierbares Buchen". 
Zu beachten ist, daB unabhangige Prozesse implizit eine neue 
Top-Level-Transaktion starten, die als "Hilf stransaktion des 
unabhangigen Prozesses" bezeichnet wird und abhangig vom 
spezif izierten Exit-Wert des Prozesses automatisch entweder 
abgebrochen oder kommitted wird. Die Funktion K_BUCHEN startet 
die Transaktion "Buchen" in der Datenbank der entsprechenden 
Institution. Wenn die Buchung im Datenbanksystem DBS durchge- 
fiihrt. (und sofort kommitted) wurde, meldet K BUCHEN die Aktion 



"STORNO der Buchung" als Kompensationsaktion in der Transaktion 
des unabhSngigen Prozesses an (d.h. wenn dieser ProzeB 
zuruckgenommen ("cancel") oder abgebrochen ( "abort" ) wird, 
nachdem er schon erfolgreich terminiert hatte, wird automatisch 
diese Aktion durchgef tihrt ) und terminiert: den ProzeB mit dem 
Exit-Wert "PREPARE" . Dies bedeutet, daB der ProzeB noch auf 
eines der Signale "ABORT", "CANCEL" oder "COMMIT" wartet. Das 
Verhalten des Prozesses im Fall der ersten beiden Signale ist 
wie schon erwahnt das Abbrechen seiner Transaktion, die die 
Ausfvihrung der Kompensationsaktion "STORNO von Buchung im DBS" 
triggert. Ein Signal "COMMIT " schlieBt die Arbeit des Prozesses 
ab, so daS dieser ab nun keine Signale mehr akzeptiert; die 
Buchung ist dann endgiiltig abgeschlossen. 

Die Hotel- und Autobuchungen werden ebenfalls parallel, aber 
als abhangige Prozesse angestartet, die die Funktion NK_BUCHEN 
( "nicht kompensierbares Buchen" ) ausfuhren. Diese Funktion star- 
tet die Transaktion "Buchen" in der Datenbank der entsprechenden 
Institution. Wenn die Buchung im Datenbanksystem DBS erfolgreich 
ist, meldet das DBS "DB_READY" zuruck, d.h. das DBS wartet nun 
solange, bis ihm ein " DB_COMMIT" oder ein "DB_ABORT" geschickt 
wird. Erst nach einem " DB_COMMIT " werden die Anderungen im DBS 
sichtbar. Wenn das DBS ein "DB__READY" retourniert, meldet 
NK_BUCHEN "DB_COMMIT" im DBS als Kommitaktion im aktuellen 
ProzeB an, d.h. diese Kommit-Aktion bezieht sich auf die Trans- 
aktion des aktuellen Prozesses, die im Fall eines abhangigen 
Prozesses jene Transaktion ist, von der der ProzeB aufgerufen 
wurde, im vorliegenden Beispiel daher die Transaktion T. Diese 
Kommit-Aktion wird daher genau dann angestartet, wenn die 
Transaktion gutgeht . 

Nachdem alle Buchungen als parallel laufende Prozesse 
angestartet worden sind, synchronisiert die Transaktion T diese 
Prozesse- Dazu werden zwei Hilf sf unktionen 

WARTE_AUF_UNABHANGIGEN_PROZESS und WARTE_AUF_ABHANGIGEN JPROZESS 
verwendet . Beide Funktionen verwenden das blockierende "Alter- 
native Warten" ( ALT_WAIT ) -Konstrukt , um auf alle iibergebenen 
ProzeBidentif izierer (PIDs) zu warten, die ja Kommunikations- 
objekte sind. Sobald ein ProzeB terminiert, setzt er automatisch 
seine PID auf den Ausgangszustand, der iiber den Exit-Wert des 
Prozesses spezifiziert wurde. Wenn also der gewiinschte Exit-Wert 
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" PREPARE " und der ProzeB ein unabhangiger ( Oder aber abhangiger) 
ProzeB ist, dann wird die PID auf "SUCCEEDED" ( oder aber 
"PREPARED" ) gesetzt, falls die Hilf stransaktion des unabhSngigen 
Prozesses erfolgreich terminieren konnte (bzw. falls die 
Hilfstransaktion des abhangigen Prozesses noch Chancen hat zu 
kommitten) . Der Wert der PID wird nun getestet, wenn das 
ALT_WAIT aktiv wird. 

War der beendete ProzeB erfolgreich, dann schickt die 
Hilf sf unktion WARTE_AUF_UNABHANGIGEN_PROZESS das Signal "ABORT" 
an alle anderen Prozesse, meldet das Schicken des Signals 
"COMMIT" an den erf olgreichen ProzeB als Konimit-Aktion der 
Transaktion T an (d.h. das Triggern des " DB__C0MMIT " wird an die 
Transaktion T delegiert ) und gibt "OK" zuriick. Ansonst schickt 
die Hilfsfunktion WARTE_AUF_UNABHANGIGEN_PROZESS das Signal 
"ABORT" an den ProzeB, der zwar das ALT_WAIT aktiviert hat, aber 
nicht erfolgreich terminierte, und startet erneut ein ALT_WAIT 
auf alle anderen Prozesse an. 

Die Hilfsfunktion WARTE_AUF_ABHANGIGEN_PROZESS verhalt sich 
f olgendermaBen: War der beendete ProzeB erfolgreich, dann nimmt 
die Hilfsfunktion W ARTE__AUF_ABH ANG I GEN_PR0 Z ESS alle anderen 
abhangigen Prozesse in Bezug auf T zuriick ( "cancel" ) und gibt 
"OK" zuriick. Dieses Riicksetzen ("cancel") entfernt einerseits 
den abhangigen ProzeB aus den Aktionen, die T ausfiihren muB (so 
als ob dieser abhangige ProzeB nie von T aufgerufen worden ware 
- das demonstriert die Eigenschaft des Zuriicknehmens ( "Trans- 
aktions-Backtracking" ) des Koordinations-System ) und schickt 
andererseits auch das Signal "ABORT" an den ProzeB, was wiederum 
den Abbruch aller direkten Untertransaktionen von T bewirkt, in 
vorliegendem Fall von Ti, d.h. die Kompensationsaktion (= 
DB_AB0RT im DBS, das noch immer im 2-Phasen-Kommit wartet ) der 
Transaktion Tl wird ausgefiihrt, da Tl schon erfolgreich termi- 
niert hatte. War der beendete ProzeB nicht erfolgreich, nimmt 
die Hilfsfunktion WARTE_AUF_ABHAENGIGEN_PROZESS den abhangigen 
ProzeB (das ist wieder eine Anwendung von "Transaktions- 
Backtracking" ) in Bezug auf T zuriick und startet erneut ein 
ALT_WAIT auf alle anderen Prozesse. 

Dieses Beispiel demonstriert, wie das Koordinationssystem 
als Steuerung fur echte Datenbanktransaktionen dienen kann, 
wobei die Datenbanken autonom, d.h. unterschiedlich , sein kdnnen 
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in Hinblick auf den unterstutzten Transaktionsmechanismus . 
Speziell wurde gezeigt, daB Datenbanken, die ein herkommliches 
2-Phasen-Kommit unterstutzen, lipd Datenbanken, die diese Eigen- 
schaft nicht aufweisen, in einet einzigen globalen Transaktion 
koordiniert werden konnen, wobei die Eigenschaft der Aufhebung 
der Isolation, von Transaktionen )des Koordinationsmodells 
ausgenutzt wurde. ] 

Weiters wird demonstriert , dhaB es mit Hilfe des 
Koordinat ions-System vipo^^ eine globale Transaktion zu 

koordiniereh, fur deren Untertransaktionen alternative 
Losungsmoglichkeiten existieren, und daB auch die Kombination 
von "2-Phasen-Kommit"/"kein 2-Phasen-Kommit " moglich ist. Es 
wird garantiert, daB nur genau die benotigten Datenbank-Trans- 
aktionen abgeschlossen werden, d.h. daB z.B. nicht zwei Fliige 
gebucht werden oder zwei Hotels. Wenn angenommen zwei Flug- 
linien-Datenbanken gleichzeitig einen Flug "kommitted" haben, 
dann wird im ALT_WAIT der Hilf sf unktion 

WARTE_AUF_UNABHANGIGEN_PROZESS indeterministisch ein Flug 
gewahlt (das wird der Prozefi sein, dessen PID schneller gesetzt 
wurde), und alle anderen Flugbuchungsprozesse werden 
abgebrochen. Wenn angenommen zwei Hotelbuchungs-Datenbank- 
Transaktionen gleichzeitig "DB_READY" gemeldet haben, dann wird 
die Hilf sf unktion WARTE_AUF_EINEN_ABHANGIGEN_PROZESS in ihrem 
ALT_WAIT auch einen der Prozesse, die diese Buchung 
ref lektieren, indeterministisch auswahlen und den anderen ProzeB 
zurucknehmen ("cancel"), was das Schicken des " DB_ABORT " an die 
entsprechende Hoteldatenbank triggert. 

Wird fiir eine Buchungsgruppe ( Flug/Hotel/Auto ) keine LOsung 
gefunden, dann wird ein Abbruch der globalen Transaktion 
aufgerufen, was wiederum ein "Abort" aller bisher erf olgreichen 
Buchungen bewirkt, so da3 zum SchluB keine Buchung durchgefuhrt 
wurde . 

Trotz all dieser Eigenschaf ten garantiert die Transaktion T 
die Atomizitat der globalen Transaktion auch im Fall von 
Netzwerkfehlern. Ob im Fall von Systemf ehlern auch Atomizitat 
garantiert wird, hangt von der Verteilungsstrategie ab, die beim 
Anlegen der ProzeBidentif izierer (PID) nach dem Start von T 
gewahlt wurde. Ist die Strategie ein zuverlassiges Protokoll 
("RELIABLE"), so wird auch im Fall eines Systemf ehlers 



- 61 - 



- 62 - 



AtomizitSt bewahrt. Wenn angenommen der Rechner, auf dem die 
Transaktion T lauft, nachdem alle Prozesse parallel angestartet 
wurden, abstiirzt, und weiters angenommen wird, daS alle Prozesse 
auf anderen Rechnern laufen als jenem, auf dem T ISuft, und daS 
z.B ein HotelbuchungsprozeB (z.B. bei Hotel I) bereits 
erfolgreich terminiert hat, muB nun, da die globale Transaktion 
durch den Absturz abgebrochen wurde, garantiert werden, daB die 
Hotelbuchung nicht durchgefiihrt wird. Beim Wiederanstart des 
Koordinations-Servers auf dem Rechner von T wird der ProzeS- 
identif izierer PID_Hotel I gefunden und erkannt, daB es sich urn 
die PID eines abhangigen Prozesses handelt, dessen Transaktion 
abgebrochen wurde. Daher wird automatisch das Signal "ABORT" an 
diesen ProzeB geschickt, was das " DB_ABORT " der Hotelbuchung 
triggert. Wenn jetzt angenommen wird, daB auch eine Flugbuchung 
gutgegangen ist, so ist im gezeigten Beispiel kein Mechanismus 
vorgesehen, der wie bei der Hotelbuchung automatisch das Storno 
triggert. Da aber Flugbuchungen kompensierbar sind, wird davon 
ausgegangen, daB der Benutzer, wenn die Rechnung fur den Flug 
kommt, ein Storno an die Fluglinie schickt. Es ist aber nicht 
kompliziert, die Transaktion T so zu andern, daB auch im Fall 
einer Flugbuchung (d.h- der mittels eines unabhangigen Prozesses 
gesteuerten Datenbank-Transaktion ) ein Abbruch automatisch 
erfolgt, wenn T abgebrochen wurde. Die notwendige AbSnderung des 
Beispiels dahingehend besteht ausschlieBlich darin, Flugbuchun- 
gen auch als abhangige Prozesse anzustarten* (und diese auch mit 
der Funktion WARTE_AUF_EINEN_ABHANGIGEN_PROZESS zu synchronisie- 
ren), wobei unverandert die Funktion K_BUCHEN aufgerufen wird. 

Die Einstellbarkeit hinsichtlich Fehlertoleranz ist somit 
leicht iiber die Auswahl der verwendeten Verteilungsstrategie 
steuerbar. Weiters ist es sehr leicht, die Semantik des 
Beispiels abhangig von anderen Anf orderungen abzuandern. Meist 
reicht die Modifikation weniger Zeilen; dies ist durch die 
Machtigkeit der vom Koordinations-System unterstutzten 
Kontrollmechanismen erklarbar . 

Die gezeigte Transaktion T kann als Komponente (d.h. als 
Untertransaktion ) in anderen Transaktionen verwendet werden. Sie 
demonstriert die Eigenschaft des nicht-kaskadierenden Kompen- 
sierens : wenn T kommitted hat, kann T nur noch als gesamtes 
Arrangement storniert werden, d.h. sollte die T umschlieBende 



- 63 - 



Transaktzion, nachdem T bereits gutgegangen ist, abgebrochen 
werden, dann wird fur T die Kompensationsaktion "STORNO der 
Parisreise" aufgerufen; damit kann die Reise, deren Hotel- und 
Autobuchungsunterkomponenten nicht kompensierbar waren, 
kompensiert werden . 

Nachfolgend wird in Tabelle 5 dieses Buchungsbeispiel in 
prozeduraler Pseudonotation veranschaulicht . 

Tabelle 5 

FUNKTION K_BUCHEN( DBS ) 

RUFE " BUCHEN" IN DBS AUF 
WENN BUCHUNG GUTGING: 

WENN DAS DBS 2-PHASEN_K0MMIT UNTERSTUTZT: SCHICKE 

"DB^KOMMIT" AN DAS DBS 
MELDE IM AKTUELLEN PROZESS "STORNO VON BUCHUNG IN DBS" 

ALS KOMPENSATIONSAKTION AN 
RUFE EXIT VON PROZESS MIT DEM EXIT-WERT "PREPARE" AUF 
ANSONST: RUFE EXIT VOM PROZESS MIT DEM EXIT-WERT "ABORT" AUF 

FUNKTION NK_BUCHEN( DBS ) 

RUFE "BUCHEN" IN DBS AUF 

WENN BUCHUNG GUTGING (D.H. DBS HAT H DB_RE ADY " GEMELDET ) : 
MELDE IM AKTUELLEN PROZESS "DB_COMMIT IN DBS" ALS 

KOMMIT-AKTION AN 
STARTE IN T EINE UNTERTRANSAKTION Tl 

MELDE IN Tl "DB_ABORT IN DBS" ALS KOMPENSATIONSAKTION 
AN 

KOMMITTE Tl 

RUFE EXIT VOM PROZESS MIT DEM EXIT-WERT "PREPARE" AUF 
ANSONST: RUFE EXIT VOM PROZESS MIT DEM EXIT-WERT "ABORT" AUF 

STARTE TRANSAKTION T 

LEGE NEUE KOMMUNIKATIONSOB JEKTE FUR DIE PROZESSIDENTIFI Z IE- 
RER PID_A, PID_B, PID_C, PID_H, PID_I , PID_V UND 
PID_W VON DER VERTEILUNGSSTRATEGIE PRY AN 

STARTE UNABHANGIGEN PROZESS ( PID A) AUF DEM RECHNER DER 
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FLUGLINIE A, DER DIE FUNKTION K_BUCHEN( A_DBS ) 
AUFRUFT 

STARTE UNABHANGIGEN PROZESS ( PID_B AUF DEM RECHNER 

DER FLUGLINIE B, DER DIE FUNKTION K_BUCHEN ( B_DBS ) 
AUFRUFT 

STARTE UNABHANGIGEN PROZESS (PID_C) AUF DEM RECHNER DER 
FLUGLINIE C, DER DIE FUNKTION K_BUCHEN( C_DBS ) 
AUFRUFT 



STARTE ABHANGIGEN PROZESS ( PID_H ) AUF DEM RECHNER DER 

H-HOTELKETTE, DER DIE FUNKTION NK_BUCHEN( H_DBS ) 
AUFRUFT 

STARTE ABHANGIGEN PROZESS ( PID_I ) AUF DEM RECHNER DER 

H-HOTELKETTE, DER DIE FUNKTION NK_BUCHEN( I__DBS ) 
AUFRUFT 



STARTE ABHANGIGEN PROZESS ( PID_V ) AUF DEM RECHNER DES 

AUTOVERMIETERS V, DER DIE FUNKTION 

NK_BUCHEN ( V_DBS ) AUFRUFT 
STARTE ABHANGIGEN PROZESS ( PID__W ) AUF DEM RECHNER DES 

AUTOVERMIETERS W, DER DIE FUNKTION 

NK_BUCHEN ( W_DBS ) AUFRUFT 

WENN ( WARTE_AUF_ABHANGIGEN PROZESS (T, PID_A, PIDJB, PID_C ) 
= "OK" UND 

( WARTE_AUF_UNABHANGIGEN_PROZESS ( T , PID_H , PID_I ) 
= "OK" ) UND 

( WARTE_AUF_UNABHANGIGEN_PROZESS ( T , PID_V, PID_W ) 
= "OK") 

MELDE "STORNO DER PARIS-REISE" ALS KOMPENSATIONSAKTION 

VON T AN 
RUFE KOMMIT VON T AUF 

INFORM I ERE KUNDEN UBER DIE REISEBUCHUNG 
ANSONST 

RUFE ABORT VON T AUF 

INFORMI ERE KUNDEN, DASS DIE REISE NICHT GEBUCHT WURDE 

FUNKTION WARTE_AUF_UNABHANGIGEN_PROZESS( T, PID1, PID2, . . . ) 

WARTELISTE SEI DIE LISTE DER PROZESSIDENTIFI ZIERER PID1, 
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PID2, .... 

LABEL: 

WENN WARTELISTE LEER 1ST: RETOURNIERE "NICHT OK" 
WARTE MIT ALT_WAIT AUF WARTELISTE: DER GEFEUERTE 
PROZESSIDENTIFIZIERER SEI PID_I 
ENTFERNE PID_I AUS DER WARTELISTE 
WENN IN PID_I "SUCCEEDED" STEHT: 

SCHICKE SIGNAL ABORT AN ALLE PROZESSIDENTIFIZIERER IN 
DER WARTELISTE 

MELDE IN T "SCHICKE SIGNAL KOMMIT AN PID_I" ALS 
KOMMIT- AKTION AN 

RETOURNI ERE " OK " 
ANSONST 

SCHICKE SIGNAL ABORT AN PID_I 
GOTO LABEL_1 

FUNKTION WARTE_AUF_EINEN_ABHANGIGEN_PROZESS(T, PID1, PID2, ...) 
WARTELISTE SEI DIE LISTE DER PROZESSIDENTIFIZIERER PID1, 
PID2, .... 

LABEL: 

WENN WARTELISTE LEER 1ST: RETOURNIERE "NICHT OK" 
WARTE MIT ALT__WAIT AUF WARTELISTE: DER GEFEUERTE 
PROZESSIDENTIFIZIERER SEI PID_I 
ENTFERNE PID_I AUS DER WARTELISTE 
WENN IN PID_I "PREPARED" STEHT: 

CANCEL ALLER PROZESSIDENTIFIZIERER IN DER WARTELISTE 
IN BEZUG AUF T 

RETOURN I ERE " OK " 
ANSONST 

RUCKNAHME VON PID_I IN BEZUG AUF T 
GOTO LABEL 1 



Wenn die Erfindung vorstehend anhand von detaillierten 
bevorzugten Ausf uhrungsbeispielen naher erlautert wurde, so sind 
doch selbstverstandlich Abwandlungen und Modif ikationen im 
Rahmen der Erfindung moglich. So sind selbstverstandlich die 
angegebenen Funktionsbezeichnungen beliebig, und die Funktionen 
kdnnen auch im Ablauf getauscht werden. 



Anspruche : 

1. System zur Koordination verteilter Programme, Dienstleistun- 
gen und Daten mit Hilfe von Anwendungsprogrammen in einem 
Netzwerk mit Rechnern, auf denen lokale Sof twaresysteme ( LSYS ) 
bedienende Koordinations-Server (CoKe) laufen, wobei gemeinsame 
Objekte als Kommunikationsobjekte zum Austausch von Nachrichten 
eingesetzt und Transaktionen zur Realisierung von Kommunikation 
verwendet werden, und die Kommunikationsobjekte durch Objekt- 
identif ikationsnummern (OID) eindeutig identif iziert werden und 
nur Prozesse mit einer Referenz auf ein Kommunikationsobjekt auf 
dieses liber den jeweiligen lokalen Koordinations-Server 
zugreifen diirfen, 

dadurch gekennzeichnet , 

daB alle Koordinations-Server zusammen als globales 
Betriebssystem festgelegt werden, 

daB die lokalen Sof twaresysteme zumindest durch Funktionen 
zur Kontrolle von Transaktionen, zum Anlegen und blockierenden 
oder nicht-blockierenden Lesen von Kommunikationsobjekten, zur 
Spezif ikation von transaktionalen Pradikaten sowie zur Erzeugung 
und Uberwachung von eindeutig identif izierten , zum Zugreifen auf 
ubergebene Kommunikationsob j ekte autorisierten Prozessen 
erweitert werden, 

und daB die Kommunikationsobjekte mit Hilfe von auf Repli- 
kation beruhenden wahlbaren Verteilungsstrategien verwaltet 
werden, von denen Anwendungsprogramme unabhangig sind. 

2. System nach Anspruch 1, dadurch gekennzeichnet, daB bei der 
Wahl der jeweiligen Verteilungsstrategie eine Basis-Strategie in 
Verbindung mit zusatzlichen, optionalen Strategief lags gewahlt 
wird . 

3. System nach Anspruch 1 oder 2, dadurch gekennzeichnet, daB 
die lokalen Sof twaresysteme vom jeweiligen Koordinations-Server 
gestartet werden. 

4. System nach einem der Anspriiche 1 bis 3, dadurch gekenn- 
zeichnet, daB Kommunikationsobjekte, auf die kein lokal laufen- 
der ProzeB mehr eine Referenz hat, vom jeweiligen Koordinations- 



Server automatisch geloscht Oder ausdriicklich freigegeben 
werden . 

5. System nach einem der Anspruche 1 bis 4, dadurch gekenn- 
zeichnet, daB liber die sich in ihrer Gesamtheit als globales 
Betriebssystem verhaltenden Koordinations- Server heterogene 
Transaktionen bzw. Unter-Transaktionen auf verschiedene Rechner 
verteilt werden. 

6. System nach einem der Anspruche 1 bis 5, dadurch 
gekennzeichnet, daB im Falle von aktualisierbaren Objekten ein 
transaktionales Lesen dieser Objekte vorgesehen wird. 

7. System nach einem der Anspruche 1 bis 5, dadurch gekenn- 
zeichnet, daB als transaktionales Pradikat das Schreiben in ein 
Objekt, das Starten einer Untertransaktion, das Verteilen eines 
Teils einer Transaktion auf einen anderen Rechner, das 

Spezif izieren einer Kompensationsaktion bzw. einer Kommit-Aktion 
vorgesehen wird. 

8. System nach einem der Anspruche 1 bis 7, dadurch 
gekennzeichnet, daB dann, wenn sicher ist, daB eine jeweilige 
Transaktion eine Vollzugsmeldung abgeben (kommitten) wird, eine 
Kommit-Aktion als Berechnung angestartet wird . 

9. System nach einem der Anspruche 1 bis 8, dadurch gekenn- 
zeichnet, daB unter den Funktionen fur Transaktionen ein 
programmierbares Rucksetzen von transaktionalen Operationen, wie 
z.B. das Lesen oder Schreiben von Kommunikationsob j ekten , fur 
den Fall, Fehler bzw. Ausfalle in den Transaktionen dynamisch 
reparieren zu konnen, vorgesehen wird. 



Ing.W/gl 
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Zusammenf assung : 

! 

■ -\ 

System zur Koordination verteilter Programme, Dienstleistun- 
gen und Daten mit Hilfe von AnWendungsprogrammen in einem Netz- 
werk mit Rechnern, auf denen legale Softwaresysteme (18, 19, 20) 
bedienende Kobrdinations-Serverj ( 21 , 22, 23) laufen, wobei 
gemeinsame Ob j ekte (9) als Komymnikationsobjekte zum Austausch 
von Nachrichten' elrigese^zt *JJ*3 Transaktionen zur Realisierung 
von Kommunikation verwendet werden, und die Kommunikations- 
objekte (9) durch Objektidentif ikationsnummern (0ID) eindeutig 
identif iziert werden und nur Prozesse mit einer Referenz auf ein 
Kommunikationsob j ekt auf dieses iiber den jeweiligen lokalen 
Koordinations-Server zugreifen durfen; hierbei werden alle Ko- 
ordinations-Server (21, 22, 23) zusammen als globales Betriebs- 
system (24) festgelegt, werden die lokalen Softwaresysteme (18, 
19, 20) durch Funktionen zur Kontrolle von Transaktionen, zum 
Anlegen und blockierenden oder nicht-blockierenden Lesen von 
Kommunikationsobjekten, zur Spezif ikation von transaktionalen 
Pradikaten sowie zur Erzeugung und Uberwachung von eindeutig 
identif izierten, zum Zugreifen auf iibergebene 

Kommunikationsob j ekte autorisierten Prozessen erweitert, und 
werden die Kommunikationsob j ekte (9) mit Hilfe von auf Repli- 
kation beruhenden wahlbaren Verteilungsstrategien verwaltet, von 
denen Anwendungsprogramme unabhangig sind. 
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Initial is ierung 
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Recovery von Daten oder Logfile 
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P sex naechster noch nicht terminierter 
INDEP Prozess, der z.Z. nicht laeuft 
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P ist leer ? 
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Prozess Manager: 



Prozess -Aufspannen (von P) 
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Ausfuehrung getriggerter Arbeit 
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R : = lokaler Request 
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1st R eine gueltige CoKe-Anfrage? 



Befehl zum An leg en und Inspizieren 
von Kommunikationsobj ekten 



Befehl zur Transaktions- 
kontrolle 



Transaktionaler Befehl 

\ 

Prozess-Befehl 



40 



39 
/ 

Feh 1 e rme 1 dung 



35 



41 
42 
43 



(27) 




r c r c- 



r c f r e r 



4/22 cr 



(44) 



45 

















Erzeugen einer neuen OID 
Anlegen einer neuen Objektstruktur 
Objektstatus := UNDEFINED 
Objektzeitmarke :- 0 
Objektstrategie := Strategie 
Objekttyp := Typ; 
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Fig. 7 
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Darf Prozess auf das Objekt zugreifen 
und ist das Objekt write-once? 
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Fehlermeldung 



Objektstatus DEFINED? 



retoumiere 
Wert des Objekts 
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Ward blockierend gelesen? 
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Fehlermeldung 
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Request wurde vom Benutzer aufgerufen 
(d-h. es gibt noch keine Read-Requesc- 
Struktur fuer diese Leseanf orderung ) ? 



Anlegen einer Read-Request -Struktur und 
Anhaengen dieser Struktur ans Objekt 



Strategic Manager; 



Objekt soil gelesen werden 
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Fig- 8 
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Existieren alle Objekte, aus der Warteliste und 

sind sie alle vom Typ write-once und 

ist Prozess berechtigt ku£ sie zuzugreifen? 



Gibe es ein Ob j eke aus Warteliste, das definiert ist? 
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Fehlermeldung 
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Request wurde vom Benutzer aufgerufen 
(d.h. es gibt noch keine Alt-Wait-Reques 
Struktur fuer diese Anforderung) ? 
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Generieren eines Alt-Wait-Requests 
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O naechstes Objekt aus Warteliste ^ 
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O ist leer? 



Anhaengen des Requests an O 



Strategic Manager: 



Objekt soil gelesen we r den 
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Erzeugen einer eindeutigen TID; 
Anlegen einer Transoktionsstruktur; 
Transaktions-Vater :» KEINER; 
Ausfuehrungszustand : = STARTED ; 
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Transaktions-Start wurde 
via LSYS API aufgerufen? 
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Transakt ions -Typ 
:= Hilf stransaktion 



Transaktions-Typ 
: = normal 
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[ Retournieren dor TID j, 86 
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Fig. 11 
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Gibt es die mit TIDvater bezeichnete Transaktion 
und ist sie im 2u stand STARTED oder FAILED? 



Erzeugen einer eindeutigen TID; 
Anlegen einer Transaktionsstruktur ; 
Transaktions-Vater := TIDvater; 
Au s f uehrungs zus tand := STARTED; 
Transaktions-Typ := normal; 
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Retournieren der TID 
und ei ner (ei ndeuti gen) 
hlachri chtennummer 
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Fig. 13 
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Transaktion ge- 
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Transaktion : = COMMITTED 



124 



125 



Konsnxt war ein 
Schwaches Trans - 
aktions-Kommit ? 




Ausf uehrungszustand dei 
Transaktion := FAILED 



Transaktions-Abbruch | 





Roc ovary 


Manager 


131 


Atomarer 


-Schritt 


ENDE 





126. 



■77 



Feh 1 e rme 1 dung 



(42) 



GM 573/9<y 



* 



Fig. 14 




R :- naechster 

DEP Prozess-Request ^ 134 
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an Objekte angehaengten 
Requests dort entfemen; 
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Transaktion an Objekten; 
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Arbeit triggern: 



Objekt-Aufwecken ( alle von 
der Transaktion gesperrten Objekte) 



Aus fuehrungs zus tand := ABORTED 
Entferne Transaktionsstruktur ; 
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end gelesen? 



167 



< 



A. 



Fehlermeldung 




171 



vermerke Zeitmarke 
des Lesezei tpunkts 
am Objekt; retourniere 
Wert, eindeutige 
Nachrichtennummer u.Zeit 



Strateffie-Manaffer 1 



Objekt soli 
gelesen werden 



v 58 



(43; 215) 



m 57 3/9! 



Fig. 20 



C 



(.159) 



160 



Besitzt Prozess Zugrif f srecht auf alle 
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Requests und Anhaengen an die 
Transaktion 
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Besitzt Prozess Zugrif f srecht auf alle 
Objekte der Kommit-Aktion sowie 
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Requests und Anhaengen an die 
Transaktion 



Retournieren einer eindeutigen 
Nachrichtennummer 
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R : ■ naechster Request! 
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Terminieren ? 
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Signal -Schicken 
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aktionalen Requests 
von Objekt an O 
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Prozess Request von O 
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Arbeit triggern: 



Behandlung transaktionalex 
Requests (von O) 
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aller Requests 
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Arbeit triggern: 
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nicht im Zustand COMMITTING ? 
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Transaktion 
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Objekt -Sperren aller Requests der 
sperrenden Transaktion zugunsten 
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ha en gen und Arbeit triggern: 



Behandlung transaktionaler 
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auf die PID ? 
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Transaktion 
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Prozess -Kreieren 
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auf die PID ? 
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Terminieren. \i> 




232 



daB er am 



— 233 



Exit-Wert 



234 



Exit-Wert PREPARE ? 



Transakt i ons- 
Hanager: 
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Hilf stransaktion 
an die Transaktion 
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Hilf stransaktion 
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beschreiben (z.B. SUCCEEDED, 
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erhaltenen Nachricht 



277 
278 



Befehl -Aus fuehren (Behandle 
Nachricht von anderem CoKe) 



V ~ 



36 



SM := Strategie des 
zu lesenden Objekts 



279 
278 



58 
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schickenden Prozesses 



278 — 



Be f ehl-Aus fuehren 
(Prozess-Schicken) 



'262 



Fig, 38 



283 



278 



SM := Strategic des PID 
Objekts des Prozesses /an den 
das Signal zu schicken ist 



Be f ehl - Aus fuehren 
( Signal -Schicken) 



— 226 



284 — 



SM := Strategic der 
PID der Hilf s-Transaktion, 
deren Requests transferiert 
werden sollen 



278 



Be f ehl -Aus fuehren 
(Trans ferieren trans - 
aktionaler Requests) 



249 



Fig. 40 



285- 



SM : = Strategie des 

au f zuraeumenden Objekts 



278 



Bef ehl -Aus fuehren 
(Garbage Collection) 



— 238 



1* 




